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This  volume  is  one  of  nine  individually  bound  volumes  that  constitute 
the  Phase  II  Final  Report  "Study  of  Embedded  Computer  Systems  Support" 
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these  volumes  were  sponsored  by  AFLC/LOEC  and  cover  a  reporting 
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1.  COMMUNICATIONS- ELECTRONICS  EMBEDDED 
COMPUTER  SYSTEMS 

1.1  INTRODUCTION 

The  Communications -Electronics  (C-E)  category  of  Embedded 
Computers  Systems  (ECS)  embraces  a  wide  variety  of  ground  based 
and  airborne  weapon  and  support  systems.  Of  all  the  ECS  categories 
C-E  is  the  most  complex  interim  of  system  types,  number  of  users/ 
support  agencies,  and  missions.  In  addition,  the  complexity  of  ECS 
support  is  growing  at  a  non-linear  rate,  as  more  systems  are  added 
to  each  category  and  each  new  system  becomes  more  technically 
complex  than  the  previous  one. 

The  primary  focus  of  this  portion  of  the  overall  study  was  to 
establish  an  ECS  support  baseline  for  representative  C-E  systems. 

The  baseline  was  then  used  as  a  reference  point  for  assessing  the 
current  level  of  ECS  support  and  for  identifying  deficiencies  in  pro¬ 
jected  C-E  support  systems.  The  baseline  will  also  serve  as  a  point 
of  departure  for  developing  a  long  range  communications-electronics 
ECS  support  plan. 

The  responsibility  for  supporting  certain  C-E  category  ECS 
systems  is  shared  by  AFLC  with  the  using  commands;  e.  g. ,  TAC,  SAC, 
and  AFCC.  The  precedent  for  this  support  concept  was  established 
by  the  Jumper-Snavely  Agreement  of  1970.  The  specific  degree  of 
sharing  is  established  via  a  Memorandum-of-Agreement  (MOA) 
between  AFLC  and  the  system' s  user  organization. 

An  additional  factor  which  impacts  on  C-E  management  is  the 
total  number  of  ALC's  providing  ECS  support.  All  ALC's  except 
San  Antonio  support  C-E  systems,  with  Sacramento  serving  as  the 
prime  support  center  for  C-E  systems. 
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1.2  DEFINITIONS 

1.2.1  Communications -Electronics 

C-E  weapon  systems  and  their  associated  ECS's  and  software 
programs  are  defined  to  be  those  systems  that  perform  the  functions  of 
command  and  control,  communications,  surveillance  and  warning,  air 
traffic  control,  intelligence,  and  meteorological  support. 

1.2.2  Integration  Support  Facility 

An  engineering  facility  established  to  support  weapon  system 
embedded  computer  systems.  It  is  made  up  of  people,  equipment, 
physical  and  environmental  facilities,  data,  documentation,  and  pro¬ 
cedures.  Its  uses  may  include  the  capability  to  simulate  missions, 
evaluate  computerized  systems  or  subsystems,  test  modifications, 
and  integrate  hardware,  software,  and  man/machine  interfaces.  It 
also  provides  a  capability  for  baseline  and  configuration  management 
of  software  configured  items. 

1.2.3  Software  Support  Facility 

A  facility  established  to  develop,  support,  and  maintain  opera¬ 
tional  software  for  embedded  computer  system.  It  is  made  up  of 
people,  equipment  data,  documentation  and  procedures  necessary  to 
develop,  code,  compile,  assemble,  check-out,  test,  and  maintain 
operational  mission  software.  These  facilities  lack  the  capability  to 
conduct  systems  integration  and  testing. 

1.2.4  Command,  Control  and  Communications 

The  process  of  and  the  means  for  the  exercise  of  authority  and 
direction  by  a  properly  designated  commander  over  assigned  forces  in 
the  accomplishment  of  the  commander's  mission.  Command,  Control 

3 

and  Communications  (C  )  functions  are  performed  through  an  arrange¬ 
ment  of  personnel,  equipment,  communications,  facilities,  and  pro¬ 
cedures  that  are  employed  by  a  commander  in  planning,  directing, 
coordinating,  and  controlling  forces  and  operations  in  the  accomplish¬ 
ment  of  the  commander's  mission. 
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1.2.5  Command,  Control  and  Communications  Countermeasures 

The  integrated  use  of  operations  security,  military  deception, 

jamming,  and  physical  destruction,  supported  by  intelligence,  to  deny 

3 

information  to,  influence,  degrade,  or  destroy  adversary  C  capabilities 

3 

and  to  protect  friendly  C  against  such  actions. 

1.3  C-E  SYSTEM  IDENTIFICATION 

The  data  collection  activity  has  identified  fifty  C-E  systems  that 
are  either  currently  operational  or  in  some  phase  of  the  pre-PMRT 
acquisition  cycle.  The  exact  number  of  C-E  systems  which  should  be 
considered  in  this  category  is  in  doubt  because  the  using  commands 
often  categorize  systems  differently  than  the  supporting  commands. 
Table  1-1  lists  the  C-E  systems  considered  in  this  study.  The 
representative  systems  selected  for  the  baseline  evaluation  are  high¬ 
lighted  with  asterisks.  Each  system  is  identified  by  the  system  number, 
its  commonly  used  short  title,  its  full  title,  and  selected  remarks. 

The  table  groups  these  systems  into  the  six  functional  C-E  areas: 
command  and  control,  communications,  meteorological,  surveillance 
and  warning,  air  traffic  control,  and  intelligence  systems. 

1.4  C-E  SYSTEMS  DEVELOPMENT 

The  C-E  category  embedded  computer  system  encompasses 
several  different  sets  of  military  missions  and  lacks  the  specific  focus 
of  the  other  ECS  categories  such  as  EW  or  ATD.  In  addition  to  this 
wide  diversity  of  missions,  the  C-E  category  must  address  both  modern 
weapon  systems  entering  the  inventory  as  well  as  those  systems  which 
were  operational  prior  to  the  development  of  ECS  support  concepts. 

In  many  cases  ECS  support  has  grown  out  of  early  ADPE  requirements. 
Initially,  in  the  late  1950's  and  early  1960's,  computers  were  used  to 
process  mission  data  (radar  signals,  displays,  etc.)  and  were  not 
integrated  into  the  system  hardware.  However,  with  the  advent  of 
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C-E  Systems  (Concluded) 


militarized  minicomputers  and  microprocessors,  many  more  system 
functions  are  now  controlled  by  the  computer  in  addition  to  the  processing 
of  mission  data.  It  was  this  integration  of  hardware  and  computer  soft¬ 
ware  that  forced  the  development  of  ECS  support  concepts  outlined  in 
AFR  800-14.  The  joint  support  of  ECS  systems  by  traditional  support 
agencies  and  by  the  systems'  operational  users  adds  on  additional 
dimension  to  the  ECS  support  problem  thus  making  the  application  of 
AFR  800-14  procedures  critical  to  the  effective  management  of  the 
weapon  system's  configuration.  Effective  software  and  hardware  con¬ 
figuration  management  can  mean  the  difference  between  victory  or 
defeat  on  today's  highly  complex  and  technical  battlefield. 

The  implementation  of  new  DOD  programs  designed  to  prepare  C-E 
systems  for  tomorrow' s  battlefield  will  significantly  impact  ECS  manage¬ 
ment  in  the  near  term.  For  example,  the  Command,  Control  and  Com* 

3 

munications  Countermeasures  (C  CM)  program  will  require  additional 

resources  not  typically  associated  with  traditional  hardware  systems 

support.  The  inherent  flexibility  of  ECS  software  makes  it  an  excellent 

3 

candidate  for  the  implementation  of  C  CM  in  C-E  systems. 

1.5  OPERATIONAL  STATUS/PMRT 

The  operational  status  of  each  C-E  system  identified  previously 
in  Section  1.3  is  shown  in  Table  1-2.  The  table  is  presented  to  indicate 
the  system  status  by  including  the  system  PMRT  date.  This  date 
represents  the  time  at  which  AFLC  is  to  accept  responsibility  for 
supporting  the  system.  Also  included  is  the  organization  that  will  be 
responsible  for  providing  software  support.  The  software  support 
philosophy  is  indicated;  i.e. ,  will  software  support  be  provided  by  a 
contractor,  by  an  Air  Force  organic  organization,  or  by  an  organic/ 
contractor  combination.  The  final  column  identifies  the  user  command. 
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Table  1-2.  C-E  Systems  Operational  Status  (Concluded) 
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2.  C-E  CATEGORY  ECS  SUPPORT  REQUIREMENTS 


This  section  identifies  a  set  of  nineteen  generic  support  requirements 
along  with  several  additional  requirements  that  are  unique  to  the  C-E 
category  of  ECS.  The  first  nineteen  requirements  are  defined  as  "generic” 
because  they  are  essentially  a  common  set  of  requirements  that  apply 
to  each  ECS  category  (OFP,  ATD,  EW,  and  ATE)  as  well  as  to  the  C-E 
category.  The  C-E  "unique"  requirements  stem  mainly  from  the  fact 
that  certain  C-E  systems  are  supported  either  partially  or  totally  by 
the  user  of  the  system,  i.e. ,  the  operational  command.  For  the  most 
part,  such  a  sharing  of  support  responsibility  is  a  situation  that  exists' 
mostly  within  the  C-E  category. 

The  generic  requirements  have  been  grouped  into  the  following 
six  functional  areas:  (1)  ECS  Change,  (2)  Change  Analysis  and 
Specification,  (3)  Engineering  Development  and  Unit  Test,  (4)  System 
Integration  and  Test,  (5)  Change  Documentation,  and  (6)  Certification 
and  Distribution.  Sections  2.1  through  2.6  provide  a  short  discussion 
of  each  of  the  nineteen  requirements,  while  Section  2.7  discusses  the 
unique  requirements.  Table  2-1  presents  a  brief  summary  of  each 
support  requirement. 

2.1  ECS  CHANGE 

Requests  for  changes  to  the  computer  programs  resident  in  a 
weapon  systems  ECS  can  stem  from  the  operational  user  for  one  of 
several  reasons.  During  system  operation,  degraded  or  improper 
system  performance  may  lead  to  the  discovery  of  a  software  computer 
program  design  error  (Class  I )  of  perhaps  a  less  serious  problem  such 
as  a  minor  software  malfunction  or  discrepancy  (Class  II).  Additionally, 
a  software  change  may  be  required  to  implement  an  enhancement  in  the 
system  or  to  update  it  from  new  intelligence  information.  For  example. 
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Table  2-1.  C-E  System  Support  Requirements  (Concluded) 


if  a  new  improved  radar  were  to  be  substituted  for  an  older  radar  in 
a  S&W  system  substantial  changes  could  be  required  in  the  ECS  software 
package.  On  the  other  hand  new  intelligence  may  require  a  change  in 
ECS  software  associated  with  countermeasures  applications. 

2.1.1  Receive  and  Process  Requests 

ECS  software  change  requests  are  expected  to  be  generated,  for 
the  most  part,  by  the  system's  user  in  response  to  newly  discovered 
software  errors  that  create  a  software  deficiency,  new  intelligence 
data  effecting  system  performance  or  in  response  to  technology  improve¬ 
ments  that  can  enhance  the  system  capability  if  implemented.  These 
formal  ECS  change  requests  are  prepared,  forwarded  to  the  proper 
ALC,  received  and  recorded  by  the  ALC,  and  entered  into  the  change 
request  processing  chain. 

2.1.2  Preliminary  Analysis  and  Problem/Deficiency  Definition 

The  first  step  in  processing  the  change  request  is  to  conduct  a 
preliminary  analysis  to  categorize  the  request  (system  deficiency,  user 
enhancement,  etc. )  and  to  determine  general  feasibility  of  implementing 
the  request.  The  request  should  be  compared  to  previous  requests  to 
ensure  its  uniqueness.  It  may  be  advisable  to  append  it  to  a  previous 
request  that  addresses  a  closely  related  problem.  In  either  case,  a 
carefully  worded  technical  statement  of  the  change  request  is  prepared 
for  further  processing. 

2.1.3  Preliminary  Resource  Allocation  and  Scheduling 

The  integration  support  facility  must  estimate  the  resources,  con¬ 
sidering  organic  and  contractor  resources,  which  are  required  to  effect 
the  requested  change.  The  required  resources  are  then  allocated  and 
the  activity  is  integrated  into  the  center's  overall  workload.  It  may  be 
necessary  to  substantially  revise  the  overall  schedule  to  accommodate 
a  high-priority  change  request.  For  less  than  high-priority  requests 
it  may  be  advisable  to  delay  processing  of  the  request  until  several  low- 
priority  requests  can  be  processed  in  a  block  mode  in  a  single  change 
cycle. 


The  block  change  mode  of  change  control  is  an  economical  method 
of  making  small  changes  in  a  relatively  dynamic  system,  however,  many 
C-E  systems  do  not  require  periodic  changes.  On  the  other  hand,  some 
systems  will  require  numerous  mission  oriented  software  changes  on 
a  priority  basis.  Specific  procedures  for  each  system  should  be  provided 
in  resource  planning  and  configuration  management  documents,  such  as 
the  CRISP  and  O/S  CMP. 

2.2  CHANGE  ANALYSIS  AND  SPECIFICATION 


To  this  point  in  the  process  the  request  change  has  been  only 
broadly  identified  and  scoped  with  an  estimated  completion  date  established. 
Prior  to  initiating  actual  development  and  integration,  it  is  necessary 
to  examine  alternative  approaches  with  respect  to  such  parameters  as 
cost,  impact  on  the  ECS  and  the  overall  weapon  system  in  terms  of  per¬ 
formance,  and  overall  feasibility.  Given  a  feasible  solution  is  found, 
the  support  center  team  will  develop  a  design  and  generate  a  Computer 
Program  Change  Proposal  (CPCP)  for  management  approval. 

2.2.1  Feasibility 

Alternate  approaches  are  conceptualized  and  examined  to  establish 
their  feasibility  to  implement  the  requested  change.  The  approach  that 
offers  the  most  timely  cost-effective  solution  is  selected. 

2.2.2  Requirements  Decomposition/Definition 

Based  on  the  selected  design  approach,  the  overall  technical 
activity  is  decomposed  into  subtasks  that  are  of  a  manageable  size. 

A  Work  Breakdown  Structure  (WBS)  approach  is  used  to  organize  the 
overall  technical  task.  This  WBS  also  will  guide  development  of  the 
subtasks  work  package  writeups  that  will  direct  the  work  package 
manager. 

2.2.3  Preliminary  Design 

A  preliminary  design,  based  on  the  previously  selected  design 
concept,  is  prepared  for  review  at  a  Preliminary  Design  Review  (PDR). 
This  design  should  be  sufficiently  detailed  so  as  to  allow  its  reviewers 
to  approve  it  for  further  design  efforts. 


2.2.4  Detailed  Design 

The  approved  preliminary  design  is  expanded  in  scope  and  detail 
to  produce  a  detailed  analytical  design  from  which  detailed  software 
specifications  can  be  written.  Test  procedures  must  also  be  specified 
to  allow  subsequent  development  of  a  detailed  test  plan.  A  Critical 
Design  Review  (CDR)  will  be  held  to  confirm  that  the  design  meets  its 
development  requirements. 

2.2.5  Generate  Change  Proposal 

The  Computer  Program  Change  Proposal  (CPCP)  is  the  technical 
description  of  the  work  to  be  performed.  It  will  serve  as  the  basis  for 
reaching  an  agreement  with  the  requester  as  to  the  adequacy  of  the 
solution  and  as  the  basis  for  obtaining  management  approval  prior  to 
entering  the  development  and  integration  phases  of  the  change  process. 
Management  approval  will  be  from  either  a  Computer  Program  Con¬ 
figuration  Sub-board  (CPCSB)  or  a  Configuration  Control  Board  (CCB). 

2.3  ENGINEERING  DEVELOPMENT  AND  UNIT  TEST 

When  the  detailed  design  presented  in  the  change  proposal  has  been 
approved,  the  next  step  in  the  change  process  iB  to  initiate  the  efforts 
to  develop  and  test  the  necessary  changes. 

2.3.1  Develop  the  Change 

The  project  team  implements  the  changes  by  preparing  the  new 
software  code  for  all  the  affected  software  modules  within  the  overall 
software  program.  If  any  hardware  changes  are  required,  all  interfaces 
must  be  coordinated  with  the  hardware  change  engineers. 

2.3.2  Perform  Engineering  TestB 

As  the  new  code  for  each  module  is  prepared  it  is  necessary  to 
conduct  unit  or  module  testing  to  ensure  the  validity  of  the  software 
changes.  These  tests  need  only  be  designed  to  test  one  module  at  a  time. 


2-7 


2.4  SYSTEM  INTEGRATION  AND  TEST 

After  the  module  level  changes  have  been  implemented  and  tested 
it  is  necessary  to  reassemble  the  ECS  software  and  perform  ECS  level 
and  weapon  system  level  testing. 

2.4.1  Test  ECS  System  Performance 

Changes  to  the  ECS  must  be  tested  with  the  ECS  viewed  as  a 
subsystem  prior  to  integration  and  test  of  the  total  weapon  system.  It 
may  be  necessary  to  provide  an  input  scenario  and  simulations  of  the 
other  components  of  the  weapon  system  to  successfully  test  the  ECS 
as  an  independent  subsystem. 

2.4.2  Test  Weapon  System  Performance 

After  the  ECS  has  been  successfully  tested  as  an  independent 
subsystem  it  can  be  integrated  into  the  total  weapon  system.  The  total 
system  is  then  tested  to  demonstrate  that  the  desired  system  performance 
improvements  have  been  attained.  These  system  level  tests  may  involve 
actual  aircraft  flight  tests  for  airborne  systems  or  the  flying  of  aircraft 
against  ground  based  systems.  This  level  of  testing  requires  user 
involvement.  In  other  cases,  the  use  of  a  simulator  may  be  necessary, 
for  example,  to  simulate  missile  launches  when  testing  an  S&W  weapon 
system. 

2.4.3  Produce  Test  Reports 

As  the  testing  progresses  it  is  necessary  to  compile  the  results 
of  individual  and  collective  tests.  Good  engineering  practice  dictates 
that  all  testing  efforts  should  rigorously  follow  the  test  plan  and  that 
all  test  results  be  carefully  recorded.  The  test  results  are  then 
collected  and  published  in  the  final  test  report.  It  is  only  after  approval 
of  the  final  test  report  that  request  changes  can  be  implemented  in 
fielded  weapon  systems. 

2.5  CHANGE  DOCUMENTATION 

All  implemented  changes,  minor  or  major,  must  be  reflected 
in  the  system's  documentation.  This  documentation  may  exist  in  the 
form  of  operators  manuals,  programmers  manuals,  technical  manuals 
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and  so  forth.  For  many  systems  the  baseline  computer  program(s) 
may  exist  on  magnetic  tape  or  disc  storage  media.  In  any  case,  all 
relevant  documentation  must  reflect  the  current  configuration  of  the 
system. 

2.5.1  Document  ECS  Change 

All  working  documents,  in  whatever  form,  must  be  updated  to 
reflect  the  changes  in  the  system.  Inadequate  or,  worse  yet,  incorrect 
documentation  can  lead  to  severe  problems  when  attempts  are  made 
in  the  future  to  respond  to  requests  for  software  changes. 

2.5.2  Update  ECS  Baseline 

The  ECS  baseline  must  be  updated  in  whatever  form  it  exists. 
This  can  include  system  specifications,  magnetic  tapes,  hardware 
drawings  and  so  forth.  All  baseline  data  must  be  maintained  current. 

2.5.3  Configuration  Control 

Good  engineering  practice  requires  that  all  system  documentation 
be  under  configuration  control.  The  implementation  of  configuration 
control  procedures  is  especially  important  in  the  final  stages  of  inte¬ 
gration  and  test  so  that  system  failures  will  not  offset  progress  made 
prior  to  the  most  recent  benchmark. 

2.6  CERTIFICATION  AND  DISTRIBUTION 

A  central  point  should  exist  within  the  office  of  the  System 
Manager  (SM)  who  has  the  authority  to  certify  the  technical  adequacy 
of  the  change  and  order  its  implementation  in  all  fielded  systems. 

2.6.1  Certify  Documentation 

Assuming  that  all  system  testing  has  been  successfully  completed 
and  all  system  documentation  accurately  updated,  it  is  the  SM's 
responsibility  to  certify  that  the  change  action  is  complete. 
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2.6.2  Distribute  Revise^  ECS  Data 


Revised  baselines  are  now  available  for  installation  in  all  fielded 
systems.  A  distribution  process  is  initiated  which  ensures  that  revised 
capabilities  and  revised  documentation  is  available  to  the  user. 

2.6.3  Provide  Installation/Procedures /Instructions 

The  user  may  install  the  changes  provided  adequate  procedures  and 
instructions  are  available  to  describe  the  installation.  Certain  updates 
may  require  specialized  personnel  and/or  procedures  which  are  not 
within  the  user  capability,  and  thus  must  be  otherwise  arranged. 

2.7  UNIQUE  C-E  SUPPORT  REQUIREMENTS 

Many  C-E  systems,  perhaps  even  most,  are  deployed  in  relatively 
small  numbers.  For  example,  COBRA  JUDY  will  have  one  site,  PAVE 
PAWS  has  only  two,  JSS  is  to  have  seven,  and  SEEK  IGLOO  will  have 
a  total  of  thirteen.  In  this  context  these  total  numbers  are  small  when 
compared  to  the  number  of  OFP's  supported  in  fighter  aircraft  pro¬ 
grams  (F-15/729,  F-16/1388). 

Regardless  of  the  number  of  systems  to  be  supported  the  most 
important  factors  in  determining  ECS  support  requirements  are  fre¬ 
quency  and  complexity  of  change.  For  example,  it  is  possible  that 
an  ECS  change  for  2000  aircraft  may  consume  fewer  resources  than 
a  single  PAVE  PAWS  change.  The  decision  to  build  a  centralized  ISF 
or  use  a  field  site  to  support  the  ECS  software  must  be  made  in  light 
of  operational  requirements,  frequency  of  change,  number  of  configu¬ 
rations  to  be  supported,  and  available  common  resources. 

Each  case  is  decided  on  a  system-by- system  basis  with  a 
Memorandum  of -Agreement  (MOA)  spelling  out  the  details  of  each 
command's  responsibilities.  In  addition  to  the  MOA,  the  CRISP  and 
the  O/S  CMP  further  define  intercommand  responsibilities  and  inter¬ 
face  relationships. 
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It  should  be  noted  here,  even  though  the  user  may  be  providing 
partial  or  even  total  support  for  the  system's  ECS  software,  that  the 
SM  retains  responsibility  for  overall  system  support.  This  places 
the  SM  in  a  situation  where  discharge  of  his  system  responsibilities 
requires  a  close  working  relationship  with  other  supporting  agencies. 

In  the  future  this  could  include  coordination  with  intelligence  collection 
and  dissemination  organizations. 

2.7.1  Operational  Support  Scenarios 

The  user  is  often  totally  or  partially  responsible  for  providing 
the  capability  to  support  the  system's  ECS  software.  The  spectrum 
of  AFLC  support,  in  the  face  of  this  potential  variation  in  user  support, 
can  be  described  by  defining  three  different  support  scenarios. 

In  the  first  case,  AFLC  has  responsibility  for  all  software  support. 
In  this  situation,  the  assigned  ALC  will  provide  the  capability  to  support 
the  totality  of  the  system's  operational,  support,  and  test  software. 

An  example  of  such  a  case  is  the  TRACALS  TPN-19/GPN-24  ECS  which 
is  to  be  supported  by  the  SM-ALC. 

In  the  second  case,  AFLC  shares  the  responsibility  for  software 
support  with  the  operational  command.  In  this  situation,  the  degree 
of  sharing  is  decided  on  a  system-by-system  basis,  based  on  the  user's 
desire  to  control  operational  software  associated  CPCI's.  AFLC  would 
then  typically  be  responsible  for  the  support  software  and  the  test  soft¬ 
ware  CPCI's.  An  example  of  this  apportionment  is  illustrated  by  the 
E-3A  AW  ACS  program.  TAC  has  responsibility  for  ten  E-3A  CPCI's 
which  are  closely  related  to  command  and  control  functions,  while 
AFLC  has  responsibility  for  the  six  remaining  E-3A  CPCI's. 

In  the  third  case,  AFLC's  system  manager  retains  system  support 
responsibility  with  the  CPC  I  support  responsibility  assumed  by  the 
user  command.  In  this  situation,  the  user  command  must  provide  the 
capability  to  support  all  of  the  ECS's  CPCI's.  An  example  of  this 
situation  is  the  Joint  Surveillance  System  (JSS).  AFLC  ECS  support 
will  be  limited  to  producing  PROM's  for  diagnostic  software. 
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2.7 .2  Support  Management 

Each  new  entry  of  a  C-E  system  into  the  acquisition  process 
presents  AFLC  with  a  requirement  to  establish  a  support  team  to  fulfill 
the  commands’  support  responsibilities  during  the  pre-PMRT  and  the 
post-PMRT  time  periods.  Support  responsibilities  during  the  pre-PMRT 
time  period  relate  mainly  to  monitoring  system  development  to  ensure 
system  supportability  after  "transition"  to  AFLC.  Post-PMRT  responsi¬ 
bilities  will  incorporate  the  complete  spectrum  of  traditional  support 
for  all  elements  of  the  system  and  are  dependent  upon  the  support 
arrangements  delineated  in  the  MOA,  the  CRISP,  and  the  O/S  CMP. 

These  responsibilities  can  be  categorized  under  the  functional 
headings  of  (1)  system  management,  (2)  system  engineering,  (3) 
hardware  engineering,  and  (4)  software  engineering.  AFLC  assigns 
the  system  support  responsibility  to  a  specific  ALC  and  then  from 
within  the  ALC's  functional  organizations,  personnel  are  designed  to 
fill  the  roles  of  System  Manager  (SM),  System  Engineer  (SE),  hard¬ 
ware  engineer,  and  software  engineer. 

The  responsibilities  of  these  key  management  and  engineering 
personnel,  at  any  point  in  time  throughout  the  system's  life  cycle, 
will  reflect  the  specific  phase  in  the  system's  life  and  other  system- 
related  factors  such  as  system  size,  complexity,  mission,  and  so  forth. 

Section  2.  7.  1  defined  three  support  scenarios  that  differ  in  the 
degree  of  sharing  of  the  software  support  responsibility  with  the 
system's  user.  On  the  surface  it  would  appear  AFLC's  involvement 
would  decrease  as  the  user  assumed  more  ECS  software  responsibilities; 
however,  this  is  not  the  case.  The  ALC  system  manager  still  retains 
configuration  responsibilities  whether  the  change  is  software  or  hard¬ 
ware.  In  many  cases  a  software  change  made  by  an  operational  user 
will  impact  systems  performance  or  exacerbate  configuration  manage¬ 
ment  problems.  Both  hardware  and  software  changes  call  for  action  by 
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the  SM.  For  example,  software  changes  made  by  operational  users 
could  impact  system  memory  allocation  or  conflict  with  AFLC  planned 
use  of  growth  memory  space.  In  real  time  systems,  added  user  functions 
can  slow  CPU  throughout,  thereby  impacting  other  software  functions. 
When  user  changes  are  implemented  in  ROM's  or  PROM's  the  config¬ 
uration  management  problem  grows  rapidly  with  each  new  configuration. 

If  the  change  impacts  PROM's  on  more  than  one  PC  board  within  the 
same  black  box  then  the  configuration  problem  increases  by  a  significant 
factor,  depending  on  the  number  of  PC  boards  involved.  Additionally, 
when  an  ECS  software  change  does  not  meet  user  expectations,  both 
the  hardware  and  software  engineer  must  work  in  concert  to  determine 
the  cuase  and  find  a  solution.  This  integrated  capacity  is  often  lost 
when  the  user  is  totally  responsible  for  ECS  software  changes  with  the 
ALC  responsible  for  the  hardware  changes.  If  both  commands  share 
responsibility  for  software  support,  the  configuration  management  of 
the  system  becomes  a  difficult  if  not  impossible  task. 

Some  systems,  due  to  operational  requirements,  must  be  sup¬ 
ported  by  a  software  support  facility  under  the  user's  control.  In 
most  cases,  however,  these  facilities  lack  the  integration  support 
capabilities  of  an  ISF. 

2.7.3  Intelligence  Support 

There  is  a  growing  trend  to  use  embedded  computers  to  give 

weapon  systems  a  rapid  configuration  change  capability.  In  the  past 

the  need  for  rapid  changes  in  ECS  software  was  limited  to  EW  and 

ATD  systems.  However,  the  introduction  of  the  Command  Control 

3 

Communication  Countermeasures  (C  CM)  programs  will  generate 

new  ECS  software  change  requirements,  in  addition  to  generating  a 

3 

host  of  new  support  problems.  Most  of  the  data  needed  to  make  C  CM 
ECS  software  changes  is  classified  secret  or  higher.  In  some  case  the 
supporting  and  background  data  required  by  the  decision  making  process 
(technical  assessments)  is  often  top  secret  and  sometimes  requires 
compartmented  access.  Data  at  these  higher  classifications  will  require 
specialized  handling  facilities  and  specially  cleared  technical  staffs  to 
work  on  specific  aspects  of  the  ECS  software  change. 
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The  full  scope  of  the  C  CM  mission  is  by  its  very  nature 
classified  and  at  this  time  is  undergoing  numerous  changes  as  responsible 
agencies  define  their  roles.  Once  these  missions  are  fully  defined, 
AFLC's  involvement  can  be  fully  assessed.  However,  as  a  support 
command  AFLC’s  involvement  could  be  significant. 

3 

This  direct  involvement  in  updating  C  CM  software  will  require 

access  to  classified  intelligence  data  bases  and  the  use  of  computerized 

retrieval  system  as  well  as  classified  storage  and  work  areas.  In 

addition,  individuals  selected  to  work  on  classified  projects  must  have 

the  proper  security  clearance  and,  in  some  cases,  special  access 

billets.  The  total  number  of  special  access  billets  required  will  depend 

3 

on  the  number  of  systems  supported  and  specific  C  CM  requirements. 
Initially,  only  a  relatively  small  number  of  special  access  billets  should 
be  required. 
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3.  C-E  CATEGORY  ECS  SUPPORT  CONCEPTS 

3.1  INTRODUCTION 

This  section  describes  the  software  support  concepts  that  are  in 
place  or  undergoing  development  by  several  USAF  MAJCOM's.  AFLC, 
as  the  primary  support  command,  will  provide  support  for  many  C-E 
systems;  however,  several  user  commands  will  be  responsible  for 
supporting  at  least  a  portion  of  the  ECS  software  in  selected  C-E  systems. 
These  commands  include  ADCOM,  TAC,  SAC,  and  AFCC  as  well  as 
AFLC.  These  command- specific  concepts  are  included  in  Section  3.2. 

Section  3.3  presents  an  overview  of  the  specific  organizations 
within  the  MAJCOM's  that  have  software  support  responsibilities.  The 
section  also  indicates  when  coordination  interfaces  are  required  and 
identifies  the  participants  on  each  side  of  the  interface. 

Section  3.4  is  included  to  describe  the  overall  management 
philosophy  being  adopted  by  AFLC  for  supporting  C-E  systems.  The 
section  includes  a  general  description  of  the  concept  of  operation  and, 
in  addition,  a  more  detailed  definition  of  the  roles  and  responsibilities 
of  the  systems  manager,  systems  engineer,  and  the  hardware  and 
software  engineers. 

Section  3. 5  presents  a  brief  description  of  the  hardware  maintenance 
philosophy  that  supports  the  hardware  elements  of  embedded  computer 
systems. 

3.2  C-E  CHANGE  CONCEPT  /PROCESS 

Within  the  USAF  the  AFLC  is  the  command  having  prime 
responsibility  for  weapon  system  logistics  support  including  software 
support  for  those  weapon  systems  having  embedded  computers.  However, 
there  are  some  exceptions  to  this  assignment  of  responsibility.  Certain 
systems,  particularly  some  of  the  C-E  systems,  have  software  support 


3-1 


1 


provided  in  part  or  in  whole  by  a  command  other  than  AFLC.  For 
example,  TAC,  SAC,  AFCC,  and  the  former  ADCOM  (now  ADTAC 
and  ADSAC)  are  the  operational  users  of  several  C-E  systems  for 
which  they  provide  significant  amounts  of  software  support.  Each  of 
these  commands  has  developed  its  own  similar,  but  not  identical,  concept 
for  providing  the  requisite  software  support.  The  following  sections 
will  describe  the  software  support  concept  as  practiced  by  each 
command.  ^  The  specific  configuration  control  concepts  employed 
by  the  individual  commands  are  derived  from  the  policy  expressed  in 
AFR  800-14  Volume  I,  Management  of  Computer  Resources  in  Systems; 
and  Volume  II,  Acquisition  and  Support  Procedures  for  Computer  Resources 
in  Systems.  Volume  I  establishes  policy  for  the  acquisition  and  support 
of  computer  equipment  and  computer  programs  employed  as  dedicated 
elements,  subsystems,  or  components  of  systems.  Volume  II  consoli¬ 
dates  procedures  that  apply  when  implementing  the  policies  of  AFR  800-14, 
Volume  I  and  other  related  publications  as  they  pertain  to  the  acquisition 
and  support  of  computer  resources.  It  applies  to  all  activities  responsible 
for  planning,  developing,  acquiring,  supporting,  and  using  computer 
resources  in  systems. 

•  AFLC  concept  -  specific  AFLC  policy  has  been  published 
in  AFLCR  800-21,  Management  and  Support  Procedures 
for  Computer  Resources  used  in  Defense  Systems.  This 
regulation  expands  and  carries  out  the  policies  of  AFR 
800-14,  Volumes  I  and  II  and  other  related  directives 
as  they  pertain  to  the  role  of  AFLC  in  support  of  defense 
systems  and  support  systems  computer  resources.  It 
applies  to  all  AFLC  field  units  responsible  for  planning, 
developing,  acquiring,  modifying,  reprogramming,  and 
using  computer  resources. 


Note:  The  reallocation  of  ADCOM  responsibilities  between  ADTAC 

and  ADSAC  is  currently  underway.  In  lieu  of  specific  ADTAC 
and  ADSAC  ECS  policies,  ADCOM  policies  are  presented 
and  discussed  under  the  assumption  these  policies  will  be 
sustained  in  SAC  /TAC  regulations  and  directives. 
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•  ADCOM  concept  -  specific  ADCOM  policy  has  been  published 
in  ADCOMR  55-111,  Configuration  Management  for  Opera¬ 
tional  ADCOM  Space  Defense  System  Computer  Programs. 
This  regulation  establishes  the  configuration  management 
concept  for  operational  space  defense  system  computer 
programs  for  which  ADCOM  has  configuration  management 
responsibilities.  These  systems  include  those  used  for 
space  surveillance,  missile  warning,  and  related  command 
control  communications.  This  regulation  implements 
portions  of  AFR  800-14  and  is  directive  upon  all  ADCOM 
units  which  operate  or  support  space  defense  systems. 

It  will  also  be  used  as  a  guide  by  all  agencies  supporting 
ADCOM  requirements. 

•  TAC  concept  -  specific  TAC  policy  has  been  published  in 
TACR  171-24,  TAF  Configuration  Management  System. 

This  regulation  establishes  a  configuration  management 
system  and  a  governing  Tactical  Air  Forces  Configuration 
Management  Board  (TAF/CMB)  to  ensure  interoperability 
of  interfaces  among  command  and  control,  weapons  and 
intelligence  systems  of  the  Tactical  Air  Forces.  It  also 
establishes  the  Interface  Standards  Subgroup  (ISS)  and 

the  Tactical  Systems  Interoperability  and  Support  Center 
(TSISC)  to  provide  technical  and  test  assistance  to  the 
TAF  CMB . 

•  SAC  concept  -  SAC'S  approach  to  providing  C-E  computer 
resource  support  is  to  follow  the  provisions  of  the  appli¬ 
cable  Air  Force  series  of  regulations  i.  e. ,  AFR  300  or 
AFR  800.  The  300  series  is  used  primarily  to  manage 
the  large  scale  command  and  control  systems,  such  as 
the  SACCS,  AABCP  and  CCPDS.  Those  C-E  systems 
associated  with  or  integrated  into  aircraft  systems  follow 
the  provisions  of  AFR  800-14  and  applicable  SACR  55-XX 
regulations. 

Following  the  guidance  in  AFR  800-14,  SAC  supports  the 
applicable  computer  resources  working  groups  and  par¬ 
ticipates  in  the  development  of  CRISP's  and  O/S  CMP's. 
When  operational  requirements  indicate  the  need  for 
rapid  reprogramming  of  operational  software,  SAC 
assumes  management  responsibility  for  portions  of  the 
software. 

•  AFCC  concept  -  AFCC  has  not  supplemented  Air  Force 
ECS  support  policy  and  procedures  as  contained  in  AFR 
800-14.  AFCC  views  its  primary  ECS  role  as  supporting 
the  operational  users.  In  this  role,  AFCC  representatives 
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actively  participate  in  the  preparation  of  CRISP  and 
O/S  CMP'  s.  Once  these  documents  are  written,  coordi¬ 
nated,  and  signed  they  serve  as  the  basic  support  agree¬ 
ment,  unless  unusual  circumstances  require  separate 
MOU’ s  or  MOA’ s. 

Finally,  it  should  be  noted  that  for  those  C-E  systems  wherein 
software  support  responsibility  is  shared  by  AFLC  with  another  command 
(for  example,  E-3A  AWACS),  a  Memorandum  of  Agreement  (MOA)  is 
developed  that  identifies  the  specific  CPCI' s  that  are  to  be  supported  by 
each  commad.  The  CRISP  and  the  O/S  CMP  will  provide  added  information 
relative  to  inter-command  interface  procedures  and  the  like. 

3.2.1  AFLC  Support  Concept 

AFLC's  generic  approach  to  providing  computer  resource  support 
to  those  C-E  system  CPCI's  for  which  AFLC  is  responsible  is  described 
in  this  section.  The  configuration  management  procedures  outlined 
below  stem  from  the  guidance  of  AFR  800-14  and  AFLCR  800-21.  These 
procedures  will  be  followed  regardless  of  whether  AFLC  is  solely 
responsible  for  the  system's  software  support  or  shares  the  support 
with  the  user  command.  However,  when  the  support  is  shared,  there 
will  be  an  increase  in  inter-command  coordination  to  ensure  that  soft¬ 
ware  changes  made  by  AFLC  do  not  impact  the  CPCI's  supported  by 
the  user. 

The  key  features  of  the  support  concept  include  the  establishment 
of  a  Change  Control  Board  (CCB)  and  a  Computer  Program  Configuration 
Sub-Board  (CPCSB).  The  CCB  is  the  senior  board  and  has  primary 
responsibility  for  all  software  and  hardware  changes  to  the  ECS.  The 
CPCSB  is  subordinate  to  the  CCB  but  nonetheless  it  has  final  approval 
for  all  pure  software  changes.  If  a  software  change  affects  hardware 
or  a  change  is  desired  that  affects  both  software  and  hardware,  the 
approval  must  come  from  the  CCB.  In  addition  to  the  CCB  and  CPCSB, 
a  screening  panel  is  established.  This  panel  will  conduct  a  preliminary 
screening  of  all  change,  enhancement,  or  modification  requests  to 
determine  whether  hardware,  software,  firmware,  and/or  documentation 
impacts  are  involved.  Similarly,  the  impacted  baseline(s)  would  be 
identified. 
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CPCI  changes  are  categorized  as  either  Class  I  or  Class  II  changes. 
A  Class  I  change  is  defined  as  a  "design"  change  while  a  Class  II  change 
is  defined  as  a  "discrepancy"  change. 

The  change  process  is  initiated  when  a  user  submits  a  Material 
Deficiency  Report  (MDR)  prepared  on  DD  Form  173,  Joint  Message 
Form.  The  basic  information  required  and  the  format  used  to  report 
the  deficiency  is  contained  in  T.O.  00-35D-54. 

Upon  receipt  of  the  MDR  at  the  appropriate  ALC  the  SM  will  have 
the  screening  panel  review  the  report  for  completion  of  information  and 
initiate  validation.  The  panel  will  make  an  initial  determination  as  to 
the  impact  on  hardware  and  software.  Depending  upon  the  initial 
assumptions  made  in  the  problem  definition,  the  MDR  may  follow  one 
of  three  paths;  i.e.  ,  hardware  only,  software  only,  or  both.  In  addition, 
the  screening  panel  will  determine  the  CPCI  change  classification  such 
as  design  (Class  I)  or  discrepancy  (Class  II).  Class  II  changes  that 
are  approved  for  action  will  go  to  the  appropriate  action  agency  for 
resolution;  if  the  change  is  disapproved  it  will  be  returned  to  the 
initiator.  If  the  problem  is  determined  to  be  a  Class  I  change  or  if  no 
approval/disapproval  is  taken  for  Class  II  changes,  the  screening  panel 
will  forward  the  change  to  the  CPCSB  for  resolution. 

The  CPCSB  will  review  the  MDR  proposed  change  and  take  action 
in  accordance  with  established  procedures.  These  procedures  are 
usually  documented  in  the  system's  O/S  CMP.  Approved  changes  will 
be  distributed  to  the  proper  action  agencies  for  resolution. 

After  approval  by  either  the  CCB  or  the  CPCSB  a  change  proposal 
will  be  prepared  to  guide  the  implementation  of  the  change. 

When  the  software  code  has  been  revised,  the  change  must  be 
integrated  and  tested.  The  extent  of  integration  and  system  level  versus 
component  level  testing  will  be  a  function  of  the  capabilities  of  the  ISF 


in  which  the  change  is  being  implemented.  ISF  capabilities  may  range 
from  simple  reprogramming  facilities,  to  more  complex  facilities 
capable  of  integration  and  testing  at  the  ECS  level,  to  extensive  facilities 
with  "hot  mockup"  components  that  allow  full  verification  and  validation 
of  the  software  and/or  hardware  change. 

In  many  cases,  the  distribution  of  the  change  to  affected  field 
sites  will  use  the  Time  Compliance  Technical  Order  (TCTO);  however, 
this  format  may  be  modified  to  meet  the  unique  requirement  of  CPCI 
change  distribution. 

Figure  3-1  illustrates  a  general  flow  through  the  change  process 
from  the  receipt  of  an  MDR  to  the  distribution  of  the  validated  change 
to  the  users.  This  figure  which  was  initially  prepared  by  SM-ALC 
(MMEC)  represents  a  generic  change  concept/process.  Even  though 
it  is  described  as  a  generic  process,  it  is  planned  that  each  C-E  system 
specific  process  to  be  implemented  at  SM-ALC  will  be  based  on  this 
activity  flow. 

3.2.2  ADCOM  Support  Concept 

ADCOM's  generic  approach  to  providing  computer  resource 
support  to  those  C-E  system  CPCI's  for  which  ADCOM  is  responsible 
is  described  in  this  section.  The  configuration  management  procedures 
outlined  below  stem  from  the  guidance  of  AFR  800-14  and  ADCOMR 
55-111.  A 8  will  be  seen,  ADCOM's  software  change  process  is  very 
similar  to  that  employed  by  AFLC. 

One  significant  difference,  however,  between  AFLC's  and  ADCOM's 
support  posture  relates  to  the  location  of  the  system's  ISF.  For  AFLC, 
the  individual  system's  ISF  is  usually  to  be  located  at  the  responsible 
ALC  facility.  For  example,  the  TRACALS  and  SEEK  IGLOO  ISF's  are 
both  to  be  located  at  SM-ALC.  For  ADCOM,  the  ISF  is  usually  located 
at  one  of  the  operating  sites.  For  example,  the  JSS  ISF  is  located  at 
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the  JSS  Region  Operation  Control  Center  (ROCC)  at  Tyndall  AFB,  FL. 

The  JSS  support  facility  is  actually  called  an  ROCC  Software  Support 
Facility  (RSSF)  instead  of  an  ISF;  however,  one  of  its  three  missions 
is  to  provide  a  means  for  implementing  CPCI  changes. 

The  key  features  of  the  ADCOM  support  concept  include  the 
establishment  of  a  Configuration  Review  Board  (CRB)  and  a  Computer 
Program  Configuration  Management  Board  (CPCMB)  for  each  system 
ADCOM  is  to  support.  These  two  boards  perform  essentially  identical 
functions  to  the  CCB  and  CPCSB  established  by  AFLC  to  support  their 
assigned  C-E  systems. 

The  ADCOM  CPCMB  is  established  to  review  and  recommend  to 
HQ  ADCOM/DOP  the  deferral,  approval,  or  disapproval  of  proposed 
modifications  to  the  configuration  of  operational  space  defense  system 
CPCI's.  Board  recommendations  will  be  a  majority  vote  of  the  members, 
with  dissensions  reported  to  the  approval  authority  (HQ  ADCOM/DOP). 

HQ  ADCOM/DOP  may  delegate  approval  authority  to  the  CRB  for  changes 
to  off-line  application  programs.  This  delegation  may  be  for  specific 
programs,  specific  types  of  programs,  or  for  all  off-line  programs. 
CPCMB  meeting  minutes,  when  approved,  become  the  official  record 
and  authority  for  the  Systems  Programming  Agency  (SPA)  to  proceed 
with  implementing  the  approved  changes. 

For  ADCOM  C-E  systems  having  only  one  site  (e.g.,  FPS-85, 
FPS-108),  the  CRB  is  established  at  the  site.  For  multi-site  systems, 
a  Site  Configuration  Review  Board  (SCRB)  is  established  at  a  site  that 
ha 8  a  computer  programming  capability.  In  either  case  the  functions 
of  the  board  are  basically  the  same. 

Figure  3-2  illustrates  the  general  flow  through  the  ADCOM  CPCI 
change  process  from  the  preparation  of  a  Program  Modification  Request 
(PMR)  or  a  Program  Change  Document  (PCD)  to  the  receipt  by  the 
requester  of  a  revised  CPCI  that  has  been  fully  tested  and  is  ready  for 
operational  use. 
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ADCOM  C-E  Software  Change  Proces 


ADCOM  Form  542,  Program  Modification  Request  (PMR),  may 
be  submitted  by  any  system  user  to  HQ  ADCOM/DOPP.  Because  the 
PMR  is  used  to  request  software  design  changes  (i.e.,  a  Class  1  change), 
a  change  to  the  CPCI  Part  I  Specification  will  normally  be  required. 

If  possible,  the  originating  agency  should  prepare  this  change,  using 
a  Program  Documentation  Discrepancy  Report  (PDDR)  as  a  cover  sheet. 

ADCOM  Form  549,  Program  Change  Document  (PCD)  may  be 
submitted  by  any  user  to  HQ  ADCOM/DOPP,  Because  the  PCD  is  used 
to  report  software  program  malfunction/discrepancy  problems  (i.e.. 
Class  II  changes),  a  change  to  the  CPCI  Part  II  Specification  will 
normally  be  required.  If  possible,  the  originating  agency  should  pre¬ 
pare  the  change  using  a  PDPR  as  a  cover  sheet. 

The  CRB  will  ensure  that  all  PMR's  and  PCD's  have  Part  I 
or  Part  II  Specification  PDDR's  attached,  if  required,  before  they  are 
sent  to  HQ  ADCOM  for  approval.  SCRB's  at  each  site  and  the  CRB 
will  critically  examine  and  evaluate  all  PMR's  and  PCD's,  ensure 
they  contain  proper  justification,  and  make  recommendations  to  the 
ADCOM  CPC  MB.  When  a  PMR  or  a  PCD  arrives  at  HQ  ADCOM,  the 
CPC  MB  chairperson  may  either  return  it  to  the  originator  for  more 
information  or  schedule  it  for  CPCMB  action. 

CPCI  changes,  both  PMR  and  PCD  types,  are  generally  scheduled 
for  inclusion  in  periodic  version  releases  (with  the  concurrence  of 
operational  sites).  The  frequency  of  those  releases  will  depend  on  the 
number  and  magnitude  of  outstanding  PMR's  or  PCD's,  available  man¬ 
power,  and  available  computer  time.  When  the  CRB  has  determined 
which  PMR' 8  will  be  included  in  a  version,  they  will  prepare  a  final 
change  to  the  Part  I  Specification  to  establish  the  allocated  baseline. 

For  long  term  projects,  the  CRB  may  authorize  design  and  code  work 
to  start  before  a  PMR  is  allocated  to  a  specific  version.  Version 
production  consists  of  three  distinct  phases:  design,  code,  and  test 
(with  possible  iterations  if  design  errors  are  discovered  while  coding 
is  in  progress  or  if  design  or  code  errors  are  discovered  during 
testing). 
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When  a  version  has  been  built  and  has  successfully  completed 
Development  Test  and  Evaluation  (DT&E),  the  CRB  will  complte 
ADCOM  Form  540.  Version  Release  Request,  listing  all  PMR's  and 
PCD's  in  the  version.  The  CRB  chairman  will  sign  the  ADCOM  Form 
540,  authorizing  delivery  of  the  version  to  operational  sites.  The 
CRB  will  then  send  a  copy  of  the  signed  ADCOM  Form  540  (along  with 
the  DT&E  Test  Plan  and  Test  Report,  and  a  Version  Description 
Document)  to  HQ  ADCOM/DOPP  and  the  system  OPR.  The  site  staff 
with  SPA  assistance,  will  develop  OT&E  procedures  to  assure  the  new 
version  meets  operational  requirements  and  conduct  the  OT&E.  Follow¬ 
ing  the  site  OT&E,  the  site  operations  officer  will  authorize  use  of  the 
new  version,  informing  HQ  ADCOM/DOPP  and  other  interested  agencies 
by  message. 

Special  processing  procedures  are  required  for  selected  CPCI's 
used  by  ADCOM  space  defense  systems.  These  are  CPCI's  that  are 
under  configuration  management  of  more  than  one  command.  Certain 
commercial,  executive,  supervisory,  and  maintenance/diagnostic 
software  is  under  the  configuration  management  of  AFLC's  Sacramento 
Air  Logistics  Center  (SM-ALC).  The  System  Programming  Agency 
(SPA)  may  tailor  this  software  for  a  specific  site  or  system.  Tailoring 
includes  deciding  which  modules  will  be  core  resident  and  which  will 
reside  on  auxiliary  storage,  changing  device  address  tables,  changing 
trace  table  lengths,  and  the  equivalent.  The  SPA  will  advise  HQ  ADCOM/ 
DOPP  of  these  changes  in  writing,  and  DOPP  will  inform  SM-ALC /MMC. 
If  code  changes  are  required,  the  SPA  will  submit  a  PMR  (filled  out  as 
completely  as  possible)  to  HQ  ADCOM/DOPP,  who  will  forward  it  to 
SM-ALC  for  action.  HQ  ADCOM/DOPP  will  be  responsible  for  status 
accounting  of  PMR's  sent  to  SM-ALC  until  they  are  either  installed  or 
returned  to  an  SPA  for  development. 

3.2.3  TAC  Support  Concept 

TAC's  generic  approach  to  providing  computer  resource  support 
to  those  C-E  system  CPCI's  for  which  TAC  is  responsible  is  described 
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in  this  section.  The  configuration  management  procedures  outlined 
below  stem  from  the  guidance  of  AFR  800-14  and  TACR  171-24. 

To  help  fulfill  their  responsibility  the  command  has  established 
a  configuration  management  system  and  a  Tactical  Air  Force  Con¬ 
figuration  Management  Board  (TAF/CMB)  to  ensure  operability  of 
interfaces  among  command  and  control,  weapons,  and  intelligence 
systems  of  Tactical  Air  Forces.  TAC  has  also  established  an  Inter¬ 
face  Standards  Subgroup  (ISS)  and  a  Tactical  Systems  Interoperability 
and  Support  Center  (TSISC)  to  provide  technical  and  test  assistance 
to  the  TAC /C MB. 

Figure  3-3  is  presented  to  show  the  relationships  among  the 
CM  groups.  The  figure  indicates  that  it  is  the  Joint  Standards  Group 
for  Tactical  C3  Systems  (JSG/TACCCS)  in  the  office  of  the  Joint 
Chiefs  of  Staff  (JCS)  that  sets  the  interoperability  standards  control 
for  the  CMB  and  all  TAC  C-E  system  CPCSB's.  The  figure  also  indi¬ 
cates  that  the  working  interface  with  AFLC  and  other  commands  is 
implemented  via  their  participation  in  ISS  functions.  The  following 
paragraphs  briefly  describe  the  role  of  each  of  the  key  groups  of 
Figure  3-3. 

The  governing  body  for  the  TAF  configuration  management  system 

is  the  TAF  Configuration  Management  Board  (TAF/CMB),  chaired  by 

HQ  TAC,  assistant  DCS  operations  for  control  and  support,  who  has 

overall  responsibility  for  the  decisions  of  the  TAF/CMB.  Membership 

2 

consists  of  the  chairpersons  of  the  individual  tactical  C  I  system 
Computer  Program  Configuration  Sub-Boards  (CPCSB's)  and  a  repre¬ 
sentative  from  both  USAFE  and  PACAF.  At  meetings  of  the  TAF/CMB 
each  member  is  prepared  to  provide  impact  statements  and/or  feasi¬ 
bility  studies  on  each  proposed  change  including  a  recommendation  on 
whether  or  not  the  proposal  should  be  implemented.  Decisions  of  the 
TAF/CMB  are  based  on  a  majority  vote  of  the  members.  Decisions 
are  recorded  in  the  TAF/CMB  minutes  and  are  formalized  by  the 
chairperson  signing  the  minutes.  The  members'  official  positions  of 
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Figure  3-3.  TAF  Configuration  Management  Relationships 
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concurrence  or  non.  concurrence  are  recorded  in  the  minutes.  The 

TAF/CMB  is  assisted  by  the  Tactical  Air  Forces  Interoperability 

Group  (TAFIG),  and  Tactical  Systems  Interoperability  and  Support 

Center  (TSISC),  and  the  HQ  TAC  staff  elements  responsible  for  opera- 

2 

tional  and  developmental  tactical  C  I  systems.  The  TAF/CMB,  with 
subgroups  designated  as  required,  performs  configuration  management 
in  accordance  with  pertinent  directives. 

The  Interface  Standards  Subgroup  (ISS)  of  the  TAF/CMB  is 
chaired  by  TAFIG  and  is  composed  of  representatives  from  the  TAFIG, 
the  TSISC,  and  from  each  of  the  TAF  Computer  Program  Configuration 
Sub-Boards  (CPCSB's).  The  chairperson  of  the  ISS  also  functions  as 
the  Executive  Secretary  of  the  TAF/CMB.  For  those  systems  and 
programs  which  have  not  been  turned  over  to  TAC,  TAF  representatives 
to  the  respective  developing  agency  configuration  control  boards  also 
participate  in  the  ISS.  The  Air  Force  Systems  Command  (AFSC),  the 
Aerospace  Defense  Command  (ADCOM),  the  Air  Force  Logistics 
Command  (AFLC),  the  Air  Force  Communications  Command  (AFCC), 
and  the  Air  Force  Intelligence  Center  (AFIC)  are  invited  to  observe  or 
participate  in  the  functions  of  the  ISS  as  appropriate.  ISS  membership 
includes  personnel  with  both  operational  and  technical  backgrounds 
which  enables  them  to  thoroughly  discuss  recommended  interface 
changes  and  to  perform  a  detailed  assessment  of  the  impact  of  the 
proposed  changes  on  any  of  the  involved  systems. 

Testing  of  the  TAF  systems  is  accomplished  by  the  Tactical 
Systems  Interoperability  and  Support  Center  (TSISC).  The  TSISC  per¬ 
forms  interoperability  testing  between  TAF  systems  and  other  service 
systems.  The  TSISC  is  administered  by  the  Tactical  Systems  Inter¬ 
operability  and  Support  Division  (HQ  TAC/ADYC)  within  the  TAC  Office 
of  Data  Automation. 
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Within  the  TAF,  a  CPCSB  is  formed  for  each  C  I  system  to 
provide  standardization  and  configuration  management  for  its  respective 
computer  programs,  as  defined  in  AFR  800-14,  and  prescribed  in 
associated  agreements /procedures. 

Configuration  control  procedures  within  TAC  for  implementing 
a  software  CPCI  change  follow  a  process  that  is  effectively  the  same 
as  that  process  followed  by  both  AFLC  and  ADCOM.  For  example, 
the  change  process  for  the  E-3A  AWACS,  as  presented  in  the  E-3A 
O/S  CMP,  has  been  reviewed  and  found  to  compare  quite  closely  with 
the  process  flow  of  both  Figures  3-2  and  3-3.  Minor  differences 
occasionally  exist  but  there  are  no  really  substantial  differences.  For 
example,  AFLC  refers  to  the  initial  change  request  as  a  Material 
Deficiency  Report  (MDR),  ADCOM  as  either  a  Program  Modification 
Request  (PMR)  or  a  Program  Change  Document  (PCD).  TAC,  on  the 
other  hand,  refers  to  the  initial  request  as  a  Software  Change  Report 
(SCR).  All  commands  treat  Class  I  and  Class  II  changes  in  a  similar 
fashion  with  Class  I  changes  (i.e.,  design  changes)  receiving  more 
attention  than  Class  II  (discrepancy  changes). 

This  section,  in  previous  paragraphs,  has  referred  to  the 

establishment  of  a  configuration  management  system  to  ensure  the 

2 

interoperability  of  interfaces  among  TAC's  C  I  system.  Although 
not  stated  explicitly,  it  is  implied  that  the  CM  system  ensures  that 
CM  procedures  are  followed  when  making  software  changes  to  TAC 
C-E  systems.  The  roles  and  responsibilities  of  TAC  CPCSB  members 
are  essentially  identical  to  those  of  AFLC  CPCSB  members.  It  is 
this  element  of  TAC's  CM  system  that  ensures  the  orderly  implemen¬ 
tation  of  a  proposed  software  change. 

3.2.4  SAC  Support  Concept 

SAC  has  not  supplemented  AFR  800-14  ECS  support  policies 
and  procedures  as  they  apply  to  C-E  systems  as  has  AFLC  with  AFLCR 
800-21.  However,  in  some  cases  they  use  SACR  55-XX  regulations  to 
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manage  ECS  system  software.  Where  ECS  subsystems  are  incorporated 
into  larger  command  and  control  systems,  SAC  uses  the  SACR  55-XX 
regulations  to  manage  software  changes.  All  ECS  software  changes 
for  command  and  control  systems  must  be  reviewed  by  the  SAC  Auto¬ 
mated  Command  and  Control  System  (SACCS)  Decision  Control  Board.  All 
proposed  changes  must  be  submitted  as  a  SACCS  change  request. 

In  addition  to  the  55  series  regulations,  SAC  supports  the  SAC 
Airborne  Command  Post  (EC -135)  and  the  Advanced  Airborne  Command 
Post  (E-4)  ADP  systems  under  3o0  series  regulations  and  AFR  800-14. 

Air  Force  management  software  is  developed  under  AFR  300  series 
and  system  software  under  AFR  800  series.  In  this  case,  the  systems 
software  is  jointly  supported  by  WR-ALC  and  SAC /AD.  The  AABCP 
mission  software  is  provided  by  SAC/AD  and  the  Defense  Communica¬ 
tions  Agency. 

3.2.5  AFCC  Support  Concept 

The  software  support  policy  followed  by  AFCC  is  briefly  described 
in  the  penultimate  paragraph  of  Section  3.2, 

3.2.6  C-E  ISF  Concept 

In  addition  to  having  a  configuration  management  system  that 
provides  a  means  for  maintaining  strict  configuration  control  of  all 
software  and  software /hardware  changes,  each  C-E  system  normally 
requires  the  development  and  acquisition  of  an  Integration  Support 
Facility  (ISF).  The  major  components  of  a  generic  C-E  ISF  are  shown 
in  Figure  3-4.  No  single  C-E  system  is  expected  to  have  this  exact 
configuration;  however,  the  systems  for  which  AFLC  has  software 
support  responsibility  are  expected  to  have  ISF's  that  are  functionally 
similar.  User  supported  systems  generally  include  C-E  systems 
where  there  is  a  relatively  small  number  of  sites.  For  these  systems 
the  ISF  configuration  is  often  unique  to  the  system.  For  example,  the 
ISF  for  the  Joint  Surveillance  System  (JSS)  as  described  in  Section  4.4 
is  composed  of  equipments  that  are  identical  to  system  equipments  and 
its  design  is  identical  to  one  complete  processing  thread  through  the 
total  system. 
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CONFIGURATION  FOR  SOFTWARE  REPROGRAMMING 


3-17 


Figure  3-4.  C-E  ISF  Components 


In  any  case,  the  dynamic  simulator  ISF  concept  of  Figure  3-4 
which  does  reflect  the  ISF  concept  for  many  C-E  systems  is  described 
more  fully  below. 

3.2.6. 1  Off-Line  Host  Processor 

An  off-line  computa  >onal  capability  provided  by  a  medium  to  large 
scale  computer  is  sometimes  used  for  engineering  data  management, 
simulation  and  flight  test  data  reduction  and  analysis,  configuration 
management,  off-line  interpretative  computer  simulations,  various 
support  and  debugging  tools,  cross-assemblers  and  compilers,  special 
simulation  routines,  and  other  software  related  tasks  that  can  be  best 
accomplished  away  from  the  dynamic  simulation  environment. 

3. 2. 6. 2  Simulation  Host  Processor 

The  simulation  host  processor  is  usually  a  standard,  off-the-shelf, 
qualified  minicomputer  and  depending  upon  its  size  and  capability  may 
also  be  used  to  accomplish  many  or  all  of  the  off-line  host  processor 
functions.  However,  this  computer  primarily  provides  the  capability 
to  drive  the  embedded  computer  in  a  real  time,  closed -loop  simulation 
mode  and  to  collect  data  from  the  target  computer  while  the  simulation 
is  running.  This  data  can  then  be  used  to  analyze  the  performance  of 
the  operational  software.  The  software  residing  in  the  simulation  host 
processor  would  include  (1)  software  routines  to  control  and  monitor 
the  interface  to  the  embedded  computer;  (2)  software  routines  to 
process  data  sent  to  and  from  the  system's  subsystems;  (3)  simulations 
for  closed-loop  operation  with  the  operational  computer  program;  and  (4) 
support  software  unique  to  the  minicomputer-like  compilers,  assemblers, 
and  operating  systems. 

3. 2. 6. 3  Interface  Hardware  Equipment 

This  element  between  the  simulation  processor  and  the  target 
computer  will  consist  of  an  interface  for  loading,  starting,  stopping, 
monitoring,  controlling,  simulating,  and  displaying  those  functions 
that  are  inherent  to  a  dynamic,  closed-loop  simulation  of  the  system's 
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operation.  The  hardware  interface  would  normally  take  the  form  of: 

(1)  a  computer  monitor  and  control  function  which  interfaces  with  the 
internal  signals  of  the  ECS  for  the  purpose  of  monitoring  the  computer's 
central  processing  unit  and  controlling  the  operation  of  the  computer 
such  as  changing  its  internal  status,  starting  and  halting  program  execu¬ 
tion,  and  like  functions;  and  (2)  hardware  interface  adaptor  units  for 
switching  and  signal  conditioning  (D/A  and  A/D),  power  distribution, 
and  control. 

3. 2. 6. 4  Target  Computer(s) 

Inclusion  of  the  weapon  system's  target  computer(s)  in  the  ISF 
results  in  an  ISF  having  the  capability  for  complete  software  repro¬ 
gramming  and  at  least  partial  testing  of  changes  to  the  operational 
software  that  executes  in  the  target  computer(s). 

3.2.6.  5  System/Subsystem  Components 

The  inclusion,  when  feasible,  of  system  components  that  operate 
under  the  control  of  the  target  computer  (such  as  radars,  operator 
displays,  etc.)  provides  a  capability  to  more  completely  test  software 
and/or  hardware  changes  to  the  system.  If  a  full  qualification  test  is 
required  prior  to  release  of  the  change  to  the  operational  user,  these 
components  or  complete  simulations  of  the  components  must  be  a  part 
of  the  ISF.  In  some  cases,  microprocessor-based  simulators  may  be 
adequate. 

3. 2. 6. 6  Flight  Test  Activities 

In  those  cases  where  safety-of-flight  considerations  are  of  concern, 
it  may  be  necessary  to  conduct  actual  flight  tests  to  prove  the  changes 
have  been  made  successfully.  With  C-E  systems  it  is  less  likely  that 
flight  tests  are  required  than  with  OFP  systems;  however,  with  C-E 
systems  such  as  TRACALS  flight  test  results  are  required  for  verifi¬ 
cation  of  changes. 
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3.3  ORGANIZATIONS  AND  INTERFACES  FOR  C-E  SYSTEM  SUPPORT 

Within  AFLC  there  are  several  ALC’s  that  are  involved  in 
providing  support  for  the  ECS  computer  resources  of  various  C-E 
systems.  SM-ALC  has  the  support  responsibility  for  some  forty  C-E 
systems  including  TRACALS,  SEEK  IGLOO,  and  JSS.  OC-ALC  has 
responsibilities  for  additional  C-E  systems.  Included  are  the  E-3A 
AW  ACS  and  the  E-4B  AABCP.  WR-ALC  is  responsible  for  supporting 
the  Joint  Tactical  Information  Distribution  System  (JTIDS),  among  others. 
OO-ALC  supports  the  Tactical  Information  Processing  and  Interpretation 
(TIPI)  system. 

Figure  3-5  illustrates  the  organizational  structure  existing  at 
SM-ALC  for  supporting  those  C-E  systems  assigned  to  SM-ALC. 

Within  this  structure,  MMEC  is  the  branch  with  the  responsibility  for 
developing  the  necessary  ECS  support  facilities  and  for  implementing 
both  software  and/or  hardware  changes  to  the  ECS.  The  figure  also 
indicates  that  MMEC  has  been  assigned  responsibility  for  selected  OFP 
systems  and  ATE  systems  as  well  as  the  assigned  C-E  systems. 

One  of  the  key  C-E  systems  described  in  Section  4  that  is  not 
supported  at  SM-ALC  is  the  E-3A  AW  ACS.  Responsibility  for  support¬ 
ing  this  system  resides  at  Tinker  AFB,  OK.  For  this  system,  the 
support  responsibility  is  shared  by  TAC  and  by  AFLC.  At  the  present 
time  TAC  supports  ten  CPCI's  while  OC-ALC  is  developing  an  AISF^ 
to  support  six  other  major  E-3A  CPCI's  and  systems  integration.  The 
TAC  support  facility  is  currently  operational  while  the  OC-ALC  facility 
has  a  PMRT  date  of  about  1982.  Figure  3-6  illustrates  the  TAC  organiza¬ 
tion  at  Tinker  AFB  that  maintains  the  E-3A  fleet  and  provides  support 
for  the  system' s  complement  of  ECS' s  for  which  TAC  is  responsible. 

The  552nd  Wing  was  organized  and  deployed  to  Tinker  AFB  during  1977. 


The  facility  at  OC-ALC  was  named  an  AISF  prior  to  the  adaption 
of  the  term  ISF. 
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OPERATIONS  TRAINING  MISSION  MAINTENANCE  I  RESOURCES 


Figure  3-6.  E-3A  AW  ACS  Computer  Resources  Support  Organization 


Figure  3-7  presents  the  structure  of  the  AFLC  units  that  are  involved 
in  current  efforts  to  develop  an  AISF  for  supporting  those  E-3A  CPCI's 
assigned  to  AFLC.  When  the  AISF  concept  has  been  finalized  this 
organization  will  become  responsible  for  acquiring  the  various  com¬ 
ponents  and  integrating  them  into  the  final  product.  As  shown  in 
Figure  3-7,  the  working  interface  between  the  OC-ALC  and  both  TAC, 
as  the  user,  and  ESD,  as  the  AW  ACS  development  SPO,  is  managed 
by  the  AISF  Program  Manager  (PM).  This  PM  is  a  member  of  the 
E-3A  SM  Branch  of  the  Acquisition  Division.  When  the  AISF  is  completed 
(PMRT  of  October  1982)  it  will  be  managed  and  operated  by  those  MME/ 
MMEC  personnel  who  are  responsible  for  providing  software  support  to 
the  F -3A.  The  TAC  side  of  the  interface  is  with  the  Deputy  for  Mission 
Support  in  the  552nd  AW  ACS  Wing.  The  ESD  side  of  the  interface  is 
within  the  office  of  the  Deputy  for  E-3A  (ESD/YW). 

Y  et  another  large  C-E  system  of  primary  concern  to  AFLC  is  the 
JTIDS.  As  noted  above,  WR-ALC  is  responsible  for  developing  a  JTIDS 
AISF  and  for  providing  support  to  those  ECS's  embedded  within  the  JTIDS. 
The  WR-ALC  has  a  Material  Management  Directorate  (MMD)  that  is 
organized  in  a  manner  similar  to  the  MMD  at  SM-ALC.  The  Computer 
Resources  Branch  (MMEC)  within  the  Engineering  Division  (MME)  is 
the  organizational  component  that  has  the  primary  JTIDS  computer 
resource  support  responsibility.  The  nature  of  the  JTIDS  system  is 
such  that  its  support  responsibility  is  partially  shared  by  TAC /Langley 
AFB,  and  TAC/Tinker  AFB.  There  is  also  a  possibility  that  the  WR-ALC 
ISF  will  be  interfaced  to  the  F-16  AISF  at  the  OO-ALC.  The  Langley 
connection  is  via  the  Tactical  Systems  Interoperability  Support  Center 
(TSISC)  in  support  of  the  TACS/TADS  program.  The  interface  manage¬ 
ment  procedures /responsibilities  are  established  in  the  JTIDS  TAC /AFLC 
Memorandum  of  Agreement  (MOA),  The  Tinker  AFB  connection  is  via 
the  TAC  portion  of  the  E-3A  ISF  in  support  of  E-3A  mission  software. 

This  interface  is  between  MME  at  WR-ALC  and  the  Deputy  for  the  Mission 
Support  in  the  552nd  AWACS  Wing  at  Tinker  AFB. 


3.4  MANAGEMENT  PHILOSOPHY /CONCEPT 
3.4.1  Concept  of  Operation 

AFLCR  800-21,  "Management  and  Support  Procedures  for 
Computer  Resources  Used  in  Defense  Systems"  delineates  AFLC  policy, 
a  concept  of  operation,  and  agency  responsibilities  (both  pre-  and 
post-PMRT)  for  those  C-E  systems  for  which  AFLC  has  system 
management  responsibility. 

AFLC  policy  prescribes,  for  each  C-E  system  to  be  supported, 
that  three  initial  primary  management  actions  be  taken.  First,  a 
Computer  Resources  Working  Group  (CRWG)  is  established.  This 
group  is  composed  of  representatives  from  HQ  AFLC,  the  appropriate 
ALC,  the  user,  the  developing  command  (AFSC),  AFALD,  and  per¬ 
haps  others. 

Second,  the  CRWG  prepares  the  Computer  Resources  Integration 
Support  Plan  (CRISP).  This  plan  is  an  AFLC  tool  for  identifying  what 
AFLC  needs  to  support  the  particular  ECS.  When  completed,  the 
CRISP  contains  a  substantial  body  of  information  including  plans/ 
procedures  to  establish  and  operate  an  Integration  Support  Facility  (ISF) 
for  the  system.  Details  of  the  ISF's  equipment,  software,  and  facility 
configuration  will  be  included,  insofar  as  they  are  known  at  the  time 
the  CRISP  is  prepared. 

The  third  action  involves  the  preparation,  by  the  CRWG,  of  the 
Operational /Support  Configuration  Management  Procedures  (O/S  CMP). 
This  document  details  all  configuration  management  procedures.  It 
also  will  specify  the  deficiency  reporting  and  change  control  procedures. 
The  O/S  CMP  is  the  document  that  fleshes  out  the  generalized  manage¬ 
ment  concept  defined  in  the  CRISP  by  specifying  the  specific  system- 
related  responsibilities  assigned  to  all  participating  organizations. 


3-25 


The  emphasis  in  the  management  philosophy  is  on  using  a 
centralized  concept  for  both  management  and  engineering  support.  A 
System  Manager  (SM)  will  be  assigned  with  responsibility  for  program 
control,  deficiency  evaluation,  system  engineering,  and  acceptance 
testing.  For  those  C-E  systems  wherein  AFLC  and  the  user  both  share 
management  and  support  responsibility  a  joint  concept  will  be  developed 
by  AFALD,  the  SM,  and  other  relevant  support  agencies  to  delegate  to 
each  organization  its  role  in  management,  engineering,  maintenance, 
and  system  modifications.  Since  each  C-E  system  may  have  unique 
support  requirements,  the  joint  support  concept  will  be  developed  on  a 
system -by- system  basis.  The  nature  and  extent  of  these  agreements 
will  be  documented  in  the  system's  CRISP  and  O/S  CMP. 

3.4.2  Support  Management 

Support  Management  is  an  activity  that  occurs  throughout  the 
entire  life  cycle  of  a  system.  It  first  starts  at  the  beginning  of  the 
system's  conceptual  phase  and  ends  only  when  the  system  is  removed 
from  the  operational  inventory  at  the  termination  of  the  deployment 
phase.  Even  though  it  is  an  on-going  process,  it  is  best  thought  of  as 
having  two  distinct  time  periods,  each  with  its  own  special  features. 

The  first  period  encompasses  the  system  acquisition  activities,  while 
the  second  period  encompasses  the  system  support  activities.  The 
key  action  that  defines  this  separation  is  the  PMRT  event.  The  following 
sections  will  describe  some  of  the  more  important  AFLC/ALC  manage¬ 
ment  roles  and  responsibilities  during  each  of  these  two  time  periods. 

3. 4. 2.1  Pre-PMRT  Management 

During  the  acquisition  phase  the  development  command,  usually 
AFSC/ESD  for  C-E  systems,  will  provide  the  overall  Program  Manager 
(PM)  who  is  responsible  for  acquiring  the  system.  The  role  of  AFLC 
during  this  time  period  is  to  also  provide  a  Program  Manager  (PM) 
who  comes  from  the  ALC  that  will  support  the  system  during  its  deploy¬ 
ment  phase.  This  PM  is  assigned  from  the  Acquisition  Division  (MMA) 
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of  the  center's  Material  Management  Directorate.  His  primary 
responsibility  is  to  ensure  that  the  developers  are  designing  a  "support¬ 
able"  system.  He  accomplishes  this  with  the  assistance  of  a  hardware 
engineer  from  the  center's  MMAR  Branch  and  a  software  engineer  from 
the  MMEC  Branch.  The  hardware  engineer  is  sometimes  also  called 
the  acquisition  engineer.  These  ALC  personnel  do  not  participate  in 
the  actual  design  process,  but  do  attend  the  technical  review  meetings 
(SRR,  SDR,  PDR,  CDR,  etc.)  and  review  relevant  design  material  to 
ensure  the  supportability  of  the  system  after  it  "transitions"  to  AFLC. 

For  example,  the  software  engineer  is  responsible  for  reviewing  the 
software  design  and  detail  specifications,  i.e.,  the  B-5  and  C-5  Speci¬ 
fications  to  ensure  the  adequacy  of  the  software  design.  During  this 
period,  the  hardware  engineer  is  generally  somewhat  less  involved  with 
the  system  than  is  the  software  engineer.  However,  his  responsibilities 
will  include  cognizance  of  ALC  equipment  and  facility  support  require¬ 
ments  for  the  post-PMRT  time  period.  One  of  his  duties  will  be  to 
ensure  that  the  support  requirements  that  are  to  be  satisfied  by  the 
system's  ISF  are  defined  in  the  CRISP. 

3. 4. 2. 2  Post-PMRT  Management 

Subsequent  to  PMRT,  the  systems  management  structure  under¬ 
goes  a  significant  change.  The  key  action  is  the  assumption,  by  AFLC, 
of  total  responsibility  for  supporting  the  system.  This  includes  the 
responsibility  for  supporting  the  system's  computer  resources  (computer 
hardware  and  computer  programs)  as  well  as  the  basic  hardware  elements 
of  the  system  such  as  radars,  operator  consoles,  and  the  like. 

The  overall  manager  of  the  system  is  now  called  the  System  Manager 
(SM).  He  is  a  representative  of  the  System  Manager  Division  (MMC) 
of  the  ALC.  In  most  cases,  the  division  chief  is  named  as  the  SM.  He 
may,  in  fact,  be  the  designated  SM  for  several  systems. 
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At  this  point  in  time,  i.  e. ,  PMRT,  several  key  personnel  are 
relieved  of  any  further  contact  with  the  system.  The  AFSC/ESD  PM 
no  longer  has  any  management  responsibility  since  the  system  is  now 
out  of  acquisition  and  has  become  operational.  The  ALC/MMA  PM 
and  the  MMAR  hardware  /acquisition  engineer  are  also  relieved  of  any 
further  responsibility  since  the  new  SM  from  MMC  has  the  overall 
system  management  role.  The  software  engineer  continues  to  hold 
his  former  responsibility.  However,  he  now  performs  his  role  in 
support  of  the  SM  rather  than  the  ALC  PM.  If  the  ALC  has  an  ISF  for 
use  in  supporting  the  system,  the  software  engineer  will  play  an  active 
role  in  its  use  in  the  software  change  process.  If  the  using  command 
is  to  support  all  or  most  of  the  software,  the  software  engineer's 
primary  role  is  to  review/assess  any  contemplated  software  changes 
to  be  implemented  by  the  user.  Although  the  user  is  to  implement  the 
software  change,  the  SM  at  the  ALC  continues  to  have  total  support 
responsibility  and  must  approve  all  software  changes.  He  uses  the 
expertise  of  the  MMEC  software  engineer  to  guide  his  decision. 

With  respect  to  hardware  engineering  support,  the  SM  draws 
on  the  personnel  within  MMC's  Engineering  and  Reliability  Branch 
(MMCR).  Thus,  the  role  that  was  previously  played  by  the  MMAR 
hardware  engineer  is  now  filled  by  MMCR  engineers.  Within  this 
branch  are  both  system  engineers  and  selected  hardware  engineers. 
Specific  hardware  engineers  are  assigned  program  responsibilities 
as  their  respective  skills  are  required.  In  addition  to  their  roles  in 
support  of  strictly  hardware  changes  to  the  system,  these  engineers 
will  also  be  involved  in  evaluating  the  affects  of  any  software  changes 
that  have  a  hardware  impact.  j 

3.5  HARDWARE  MAINTENANCE  PHILOSOPHY /CONCEPT 

For  the  past  several  years  the  Air  Force  and  AFLC  have  used  a 
tri-level  concept  for  maintenance.  The  levels  of  maintenance  within 
this  concept  are  identified  as  organization,  intermediate,  and  depot. 
The  basic  tenet  of  this  approach  is  that  certain  repair  is  most  cost 
effective  if  completed  at  an  individual  organizational  level,  while  other 
repairs  indicate  a  composite  or  pooling  of  equipment  and  personnel 
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is  most  efficient.  This  latter  case  represents  the  intermediate  level 
between  organizational  and  depot  levels.  Certain  other  repair  activities 
necessitate  extensive  equipment  and  expertise  such  that  the  additional 
equipment  and  qualified  personnel  consolidated  at  the  depot  level  is 
necessary  for  efficient  repair  completions. 

Using  the  described  concept,  item  maintenance  of  ECS  C-E 
systems  is  essentially  the  same  as  for  non-ECS  systems,  that  is,  when 
depot  level  maintenance  is  required,  a  Technical  Repair  Center  (TRC) 
is  responsible  for  providing  automatic  testing  where  applicable  and 
repairing  black  boxes  as  their  deficiencies  are  discovered.  One  deviation 
from  normal  is  begun  when  support  is  required  for  a  C-E  support 
system,  such  as  an  IBM  370  computer.  The  support  system  may  be 
commercial  equipment  or  "one  of  a  kind"  for  which  no  repair  capability 
may  exist  at  any  TRC.  This  means  that  subscription  service,  if  avail¬ 
able,  must  be  bought  from  the  equipment  manufacturer  and  the  responsi¬ 
bility  for  black  box  maintenance  contracted. 

The  overriding  AFLC  philosophy  is  to  use  current  AFLC  manage¬ 
ment  and  repair  policies  where  possible,  and  to  use  individualized 
system  maintenance  as  a  last  report  alternative. 


4.  REPRESENTATIVE  SYSTEMS  AND  SUPPORT  SYSTEMS 


This  section  describes  Aive  representative  C-E  systems  selected 
for  an  in-depth  analysis  as  to  the  adequacy  of  their  existing /planned 
post-PMRT  software  support  posture.  The  five  systems  have  been 
chosen  from  a  total  set  of  some  fifty  C-E  systems  (see  Table  1-1  of 
Section  1) .  The  specific  systems  have  been  selected  to  represent  a 
variety  of  PMRT  dates  and  a  variety  of  command  and/or  installations 
having  software  support  responsibility.  The  specific  systems,  their 
PMRT  date,  and  the  software  support  organization  are  presented  in 
Table  4-1. 

As  can  be  seen  in  the  table,  both  the  TRACALS  and  SEEK  IGLOO 
systems  are  completely  supported  by  SM-ALC.  That  is,  SM-ALC 
will  have  an  ISF  for  each  system  and  will  be  responsible  for  supporting 
all  system  CPCI's,  be  they  operational  CPCI's  or  test  and  diagnostic 
(support)  CPCI's.  E-3A  AW  ACS  support  responsibility  will  be  shared 
by  TAC  and  OC-ALC.  TAC  (552nd  AW  ACS  Wing)  is  primarily  responsi¬ 
ble  for  the  Airborne  Operational  Computer  Program  (AOCP)  that  resides 
in  the  E-3A's  central  computer,  while  OC-ALC  is  responsible  for  the 
airborne  surveillance  radar  program  that  resides  in  the  radar  computer. 
Each  is  also  responsible  for  portions  of  the  various  support  and  test 
software  packages.  As  shown,  ADTAC  (formerly  ADCOM)  is  completely 
responsible  for  maintaining  the  JSS  CPCI's.  ADTAC  and  SM-ALC  are 
currently  discussing  whether  SM-ALC  or  ADTAC  will  support  the 
Diagnostic  Set  (DIS)  CPCI.  The  final  decision  has  not  yet  been  made, 
however,  this  report  assumes  ADTAC  will  support  the  total  JSS  soft¬ 
ware  complement.  Finally,  JTIDS  CPCI's  are  shown  to  be  shared 
between  WR-ALC  and  TAC  HQ  (Langley  AFB).  TAC  is  responsible 
for  the  operational  computer  programs  in  one  of  the  ASIT's  two 
computers  (IBM  ML-1). 


Each  of  the  following  subsections  will  present  (1)  a  general 
description  of  the  selected  system  with  emphasis  on  the  ECS  and 
associated  CPCI's  (2)  a  description  of  the  existing/planned  support 
system  including  a  functional  schematic  of  the  ISF,  and  (3)  an  assess¬ 
ment  of  the  adequacy  of  the  current/planned  support  posture,  i.  e. , 
does  it  or  will  it  meet  the  inherent  requirements,  and  is  it  in  accordance 
with  the  general  concept  for  supporting  ECS  software. 

The  Support  Posture  Evaluation  subsections  in  each  of  the  follow¬ 
ing  Sections  (4.1  through  4.5)  contain  qualified  judgements  about  the 
system's  support  posture  that  should  prove  correct  if  the  ISF's  are 
completed  as  presently  planned. 

4.1  TRACALS  -  404L 

4.1.1  System  Description 

Traffic  Control  and  Landing  System  (TRACALS)  is  included  as 
part  of  project  404L.  The  overall  objective  of  this  project  is  to  pro¬ 
vide  fixed  and  mobile  ground  facilities  and  equipments  and  associated 
electronics  for  safe  and  expeditious  aircraft  movements  on  a  world¬ 
wide  basis.  Included  in  this  on-going  program  are  two  systems  that 
are  of  interest  to  this  study.  These  two  systems  are  the  AN/TPN-19 
and  the  AN/GFN-24(V)  Landing  Control  Centrals  (LCC's). 

The  AN/TPN-19  LCC  is  a  highly  mobile,  self-contained,  ter¬ 
minal  area  ATC  system  used  to  support  both  tactical  air  base  and 
emergency  mission  support  requirements.  The  system  is  composed 
of  the  AN/TPN-24  ASR,  the  AN/TPN-25  PAR,  and  an  operations 
center  (OPS).  Current  plans  call  for  11  systems  to  be  procured. 

The  AN/GPN-24(V)  LCC  was  developed  to  satisfy  the  fixed  based 
portion  of  the  USAF  air  traffic  control  requirements.  The  system 
was  designed  to  provide  modern  reliable,  air  transportable  terminal 
radar  system  support  of  worldwide  operations,  and  is  composed  of 
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four  segments:  (a)  AN/GPN-20  Airport  Surveillance  Radar  (ASR), 

(b)  AN/GSN -12  Operations  Center  (OPS),  (c)  AN/GPN-22  High 
Performance  Precision  Approach  Radar  (HI-PAR),  and  (b)  AN/FPN-62 
Normal  Performance  Precision  Approach  Radar  (N-PAR).  Current 
plans  call  for  39  systems  to  be  procured. 

The  AN/TPN-19  system  has  been  an  operational  system  since 
about  1976.  However,  the  TPN-19  SPO  (ESD/OCN)  and  prime  con¬ 
tractor  (Raytheon)  are  still  providing  software  support  to  the  system. 

SPO /contractor  support  has  continued  past  the  system's  IOC  primarily 
to  finish  correcting  deficiencies  that  were  discovered  prior  to  IOC. 

Also  the  ISF  at  SM-ALC  was  not  operational,  however,  present  schedules 
call  for  this  situation  to  change  by  late  1980  as  the  SM-ALC  develops 
the  TRACALS  ISF  and  thus  a  capability  to  provide  software  support 
to  the  system. 

The  GPN-24  system  is  presently  in  the  final  stages  of  its  test 
program  and  has  a  scheduled  PMRTD  of  September  1980.  Due  to  the 
similarity  of  these  two  systems,  current  plans  at  SM-ALC  indicate 
hat  they  will  both  be  supported  using  the  same  ISF. 

The  computer  resources  of  the  LCC  system  include  two  separate 
ECS's.  The  primary  ECS  is  a  specially  designed  Target  Data  Computer 
(TDC)  which  stores  and  executes  the  radar  operational  program.  The 
TDC  program  accepts  operator  target  designations  in  order  to  acquire 
and  track  up  to  six  targets  simultaneously.  The  TDC  provides  the 
final  approach  controllers  with  filtered  estimates  of  the  range, 
azimuth,  and  elevation  of  tracked  targets.  The  TDC  scans  a  volume 
+  10°  in  azimuth  and  from  -1°  to  7°  or  14°  in  elevation.  The  radar 
beam  swell  for  target  tracking  is  time- shared  between  scan  beam 
dwell  time. 

The  second  computer  is  a  TI  980B  hard-wired,  non-programmable 
processor.  It  is  part  of  the  AN/GSN-12  Operations  Center  and  provides 
display  information  to  the  operator  display  consoles. 
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The  TDC  software  package  includes  both  functional  and  diagnostic 
software  programs.  The  functional  software  is  included  in  one  CPCI 
while  the  diagnostic  software  consists  of  two  CPCI' s. 

As  shown  in  Figure  4-1,  the  TDC  operational  program  is  the 
center  of  the  PAR  control  system.  The  TDC  sends  radar  beam  angle 
commands  to  the  Antenna  Beam  Position  Control  (ABPC),  which  con¬ 
trols  the  phase  of  the  elements  of  the  array  antenna.  Target  range 
data  is  transmitted  to  the  Video  Processor  (VP)  which  gates  radar 
signal  returns  and  sends  the  TDC  both  range  and  beam  pointing  errors. 
Operator  target  designations  and  PAR  mode  commands  are  processed 
by  the  TDC,  while  target  and  scan  data  are  displayed  graphically  on 
the  CRT's  of  the  display  consoles.  In  addition,  the  TDC  program 
accepts  and  processes  runway  site  parameters  as  indicated  on  the 
Site  Parameter  Panel  (SPP). 

This  program  includes  the  following  functions: 

•  An  overall  executive  control  of  all  program  components. 

•  Initialization  of  the  program  components. 

•  The  data  processing  required  to  enable  the  acquisition 
of  targets  selected  by  Ground  Control  Approach  (GCA) 
radar  operators. 

•  The  presentation  of  tracked  target  data  and  glide  path 
data  to  GCA  operators. 

•  Automatic  recovery  from  computer  faults  due  to 
transient  power  failure,  illegal  computer  instruction, 
and  computer  program  overtime  run. 

•  Detection  of  computer  program  faults  and  peripheral 
interface  faults. 

The  diagnostic  CPCI's  include  a  System  Performance  Assessment 
(SPA)  program  and  a  computer  diagnostic  program  for  automatic 
checkout  of  the  TDC  computer  hardware. 
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Figure  4-1.  Target  Data  Computer  Interfaces 


The  TDC  in  both  the  TPN-19  and  the  GPN-24  is  a  militarized, 
general  purpose,  minicomputer  (RAC  251)  with  a  32 -bit  word  length 
and  4K  resident  core  memory.  The  program  size  for  the  three  CPCI's 
in  terms  of  the  number  of  instructions  is  as  follows:  Operational,  3.8K; 
SPA,  3.4K;  and  computer  diagnostic,  4.  OK. 

The  TI  980B  does  not  use  software  as  such.  Production  drawings 
for  Integrated  Circuits  (IC's)  will  identify  ROM  pattern  requirements. 

4.1.2  Support  System 

4. 1.2.1  Software  Support 

The  SM-ALC  (MMEC)  is  assigned  the  responsibility  of  providing 
software  support  to  both  Test  and  Diagnostic  (T&D)  and  operational 
computer  programs  for  the  AN /TPN-19  and  the  AN/GPN-24(V)  Landing 
Control  Centrals.  That  is,  SM-ALC  will  support  the  reprogramming 
of  all  software  that  executes  in  the  TDC  computer  of  each  system. 

Any  reprogramming  of  the  firmware  in  the  TI  980B  processors  will 
be  the  responsibility  of  the  WR-ALC. 

SM-ALC  has  prepared  a  3 -phase  plan  that,  when  implemented, 
will  provide  an  ISF  to  support  both  the  TPN-19  and  GPN-24. 

The  Phase  I  configuration  of  the  ISF  will  incorporate  an  HP-1000 
minicomputer  as  the  host  processor  (complete  with  associated  peripherals), 
a  target  data  computer  (RAC  251),  and  the  necessary  interface  equip¬ 
ment.  A  software -based  simulator  will  be  developed  and  integrated 
to  provide  a  means  for  modelling  the  TPN-19/GPN-24  peripheral  hard¬ 
ware.  This  configuration  will  be  somewhat  limited  in  capability  in  that 
it  will  be  able  only  to  resolve  pure  software  problems.  Phase  I  is  scheduled 
for  operation  by  December  1980. 

The  Phase  II  configuration  will  incorporate  up  to  four  Motorola 
68000  16-bit  microprocessors  to  model  the  TPN-19/GPN-24  peripheral 
hardware.  The  configuration  will  enhance  the  Phase  I  capabilities  by 
aiding  the  capability  to  resolve  software/hardware  integration  problems 
and  to  develop  enhancements.  Phase  II  is  scheduled  for  operation  by 
November  1981. 


The  Phase  III  configuration  will  allow  the  replacement  of  the 
microprocessors  that  are  simulating  the  peripheral  hardware  with 
actual  peripheral  hardware.  This  change  will  provide  several  enhance¬ 
ments:  troubleshooting  of  system  hardware  will  be  possible,  software 
development  and  evaluation  will  be  more  readily  accomplished,  the 
capability  will  exist  to  perform  independent  verification  and  validation 
of  system  modifications,  and  the  facility  will  be  able  to  support  the 
technical  repair  center  [SM-ALC  (MAI)]  responsible  for  depot  repair 
of  the  TDC.  The  operational  date  of  this  configuration  has  not  yet 
been  determined. 

Figure  4-2  illustrates  the  specific  components  of  the  TRACALS  ISF, 
4. 1.2. 2  Hardware  Support 

The  maintenance  concept  for  the  TPN- 19/GPN-24  computer 
hardware  is  essentially  a  2 -level  concept  instead  of  the  standard 
3 -level  concept.  The  organizational  level  and  the  intermediate  level 
are  basically  combined  into  a  single  Org/Int  level.  At  this  level  the 
site  personnel  will  use  the  diagnostic  software  to  isolate  faults  to  the 
failed  boards  within  the  TDC.  The  failed  boards  will  be  replaced 
by  operable  boards  with  the  failed  boards  returned  to  the  depot  for 
repair.  SM-ALC  (MAI)  is  the  designated  Technical  Repair  Center 
(TRC)  for  performing  depot  maintenance  on  the  TPN-19/GPN-24  TDC. 

WR-ALC  is  responsible  for  both  computer  hardware  and  firm¬ 
ware  maintenance  on  the  TI  980B  computer. 

4.1.3  Support  Posture  Evaluation 

The  TRACAL  ISF  is  currently  in  the  early  stages  of  implementation 
at  SM-ALC  and  is  not  yet  operational.  This  facility  was  designed  to 
support  both  the  AN/TPN-19  and  the  AN/GPN-24.  The  TPN-19  CRISP 
and  O/S  CMP  have  been  signed  and  are  available  to  guide  the  manage¬ 
ment  of  ECS  support.  On  the  other  hand  the  CRISP  and  O/S  CMP  for 
the  GPN-24  have  not  been  signed.  Both  of  these  documents  are  in 
draft  awaiting  further  review  and  coordination.  These  documents  should 
be  completed  prior  to  PMRT.  The  GPN-19  PMRT  took  place  in  1979. 
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Table  4-2  presents  an  assessment  of  the  planned  TRACALS 
support  posture  when  compared  to  the  ECS  support  requirements 
presented  in  Section  2.  The  comments  are  grouped  by  the  six  func¬ 
tional  categories  listed  in  Section  2. 

4.2  SEEK  IGLOO  -  AN/FPS-117 

4.2.1  System  Description 

The  SEEK  IGLOO  program  will  provide  improved  operational 
capability  for  the  Alaskan  Air  Command's  (AAC)  thirteen  radar  sensor 
sites  (plus  a  system  training  facility)  and  will  significantly  reduce  life 
cycle  costs  through  implementation  of  a  Minimally  Attended  Radar 
(MAR)  concept.  This  concept  requires  existing  equipment  (the 
AN/FPS-93A  surveillance  radar,  supplemented  by  the  AN/FPS-6/90 
height  finder  at  nine  of  the  thirteen  locations)  to  be  replaced  with  a 
single  current  generation  3D  radar  system  having  integral  height 
finding  capability,  improved  beacon  equipment,  and  greater  reliability/ 
maintainability.  The  current  generation  radar  equipment  will  also 
have  built-in  fault  detection  and  isolation  functions  which  enable  on-site 
personnel  to  isolate  and  replace  failed  components.  Other  automatic 
features  include  jamming  strobe  reporting  as  well  as  digital  extraction 
and  narrow-band  remoting  of  target  information.  Implementation  of 
the  MAR  system  with  the  JSS  ROCC  will  eliminate  the  need  for  radar 
operations  personnel  at  the  radar  sites  and  will  result  in  substantial 
reductions  in  remote  radar  sites  maintenance  manning  to  a  maximum 
of  three  personnel  per  site. 

The  MAR  system  will  provide  surveillance  and  ground  control 
intercept  at  distances  up  to  200  nautical  miles  and  improved  detection 
in  heavy  ground,  sea,  and  weather  clutter.  Each  radar  will  provide 
search,  height,  beacon  identification,  strobe,  and  other  data  for 
transmission  to  the  Region  Operations  Control  Center  (ROCC)  at 
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Table  4-2.  TRACALS  Support  Posture  Status 


Support  Requirements 

F  inding  s  /  R  ema  rk  s 

ECS  Change 

ISF  is  hot  operational  and  the  contractor 
continues  to  support  the  software.  The 

ISF  description  in  the  GPN-24  CRISP 
does  not  fully  identify  all  required 
resources  to  support  the  reprogramming 
facility  (manpower,  space,  specific 
support  software,  etc.) 

Change  Analysis  and 
Specification 

A  support  team  has  been  assigned  to  the 
ISF,  but  CPCI's  are  currently  maintained 
by  the  contractor. 

Engineering  Development 
and  Unit  Test 

Requirements  are  adequately  covered  in 
the  draft  O/S  CMP;  however,  specialized 
engineering  development  and  test  soft¬ 
ware  is  not  described  in  the  CRISP. 

System  Integration 
and  Test 

Requirements  are  adequately  covered  in 
the  draft  O/S  CMP.  The  requirements 
for  system  test  and  evaluation  software 
are  not  called  out  in  the  CRISP. 

Change  Documentation 

Normal  CPEN  reporting  will  be  used. 

Rapid  changes  to  the  CPCI  are  not  antici¬ 
pated  and  this  method  of  reporting  is 
assessed  to  be  adequate. 

Certification  and 
Distribution 

A  TCTO  will  be  used  to  distribute  changed 
CPCI's  and  related  change  documents. 
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Elmendorf  AFB,  thus  supporting  implementation  of  the  Joint 
Surveillance  System  (JSS)  program  in  Alaska.  The  capability  will 
also  exist  for  limited  autonomous  operation  in  the  event  of  failure  of 
either  the  communication  path  to  the  ROCC  or  the  ROCC  itself. 

The  SEEK  IGLOO  MAR's  will  be  developed  in  three  phases. 

Phase  I  was  a  six  month  design  validation  phase  involving  three  con¬ 
tractors.  The  participating  contractors  completed  by  submitting  Type 
B  Specifications  and  conducting  a  Preliminary  Design  Review  (PDR) 
for  evaluation.  A  second  selection  process  was  conducted  at  the  end 
of  Phase  I.  One  contractor  was  selected  and  entered  Phase  II  (full 
scale  development).  Phase  II  consists  of  fabrication  and  developmental 
testing  of  two  pre-production  radars  to  include  IOT&E  of  one  MAR 
at  King  Salmon  APRT,  Alaska.  Following  Phase  II,  a  production  con¬ 
tract  will  be  awarded  commencing  the  third  and  final  phase.  Phase  III 
includes  the  refurbishment  of  the  two  preproduction  MAR's,  production, 
delivery,  and  installation  of  12  SEEK  IGLOO  MAR's,  delivery  of  a 
training  system,  and  delivery  of  depot  support  equipment.  The  General 
Electric  Company  is  currently  performing  on  Phase  II  of  the  program. 

The  computer  resources  of  a  SEEK  IGLOO  MAR  site  include 
four  different  kinds  of  ECS's.  They  are  as  follows: 

1.  General  Electric  -  Federation  of  Functional  Processor/ 
Digital  Data  Processor  (FFP/DDP).  This  is  a  mini¬ 
computer  with  a  16 -bit  word  length  and  2  Mbytes  of 
memory. 

2.  Texas  Instruments  -  TI  9900  Microprocessor. 

3.  Advanced  Micro  Devices  -  AMD  2900  Microprocessor. 

4.  Intel  8086  Microprocessor. 

There  are  six  separate  Functional  Application  Software  (FASW) 
CPCI's  that  are  being  developed  for  execution  in  these  computers. 
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The  following  paragraphs  briefly  describe  each  of  these  CPCI's. 

•  Data  Processor  Mission  Software  (DPMS).  The  DPMS 
CPCI  is  resident  in  the  Digital  Data  Processor  (DDP) 
and  performs  routine  radar  control  functions  associated 
with  the  maintenance  of  surveillance  beams  and 
Monitoring /Fault  Isolation  (M/FI),  Target  and  strobe 
detections  from  the  radar  and  target  identification  from 
the  Beacon  Interrogator  are  processed  and  reported 

to  the  ROCC.  The  DPMS  CPCI  provides  for  the 
generation  of  radar  system  test  commands,  the  collec¬ 
tion  of  test  data,  and  the  reporting  of  test  conclusions. 
DPMS  also  provides  automatic  reconfiguration  around 
failed  redundant  elements. 

•  Display  Mission  Software  (DMS).  The  DMS  CPCI  is 
resident  in  the  TI/SPB  9900  Microprocessor,  an  element 
of  the  display  data  processor  in  the  Operations  Control 
Group.  The  DMS  CPCI  supports  operator-entered 
initialization  commands,  manual  initiation  of  targets, 
allows  the  entering  of  console  control  messages,  and 
supports  other  operator-entered  commands. 

•  Beacon  Mission  Software  (BMS).  The  BMS  CPCI  is 
resident  in  the  Intel  808^  microprocessors,  an  element 
of  the  beacon  interrogation  and  processing  equipment 
in  the  Process  and  Control  Group.  The  BMS  CPCI 
designates  SIF  mode  interrogation  codes  according  to 
predetermined  interface  patterns,  performs  fault 
monitoring  and  isolation  tests,  accepts  decoded  IFF 
video  for  target  identification,  and  reports  reply  code 
and  azimuth  information  to  the  DDP. 

•  Radar  Support  Software  (RSS).  The  RSS  CPCI  is  resident 
in  the  DDP  in  the  off-line  mode.  The  RSS  CPCI  provides 
M/FI  capability  for  all  elements  of  the  MAR  system 
except  the  DDP  (which  is  performed  by  the  existing  DP 
off-line  diagnostics).  RSS  initializes  off-line  M/FI 
programs  for  the  radar  system,  controls  the  execution 
of  test  sequences,  analyzes  test  data,  and  reports 
M/FI  test  results. 

•  Data  Processor  Support  Software  (DPSS),  The  DPSS 
CPCI  is  an  existing  program  for  DP  off-line  diagnostics. 

•  Data  Processor  Operating  System  (DPOS).  The  DPOS 
CPCI  is  an  existing  program  to  permit  operation  of  the 
GE  FFP/DDP  compute-. 


4.2.2  Support  System 
4 . 2 . 2 . 1  Software  Support 

The  SM-ALC  (MMEC)  is  assigned  the  responsibility  of  providing 
software  support  to  both  Test  and  Diagnostic  (T&D),and  operational 
computer  programs  for  the  SEEK  IGLOO  MAR  systems.  That  is, 
SM-ALC  will  support  the  reprogramming  of  all- software  that  executes 
in  the  GE  FFP/DDP  computer.  SM-ALC  will  also  support  the  repro¬ 
gramming  of  all  firmware  in  the  TI  9900,  AMD  2900,  and  Intel  8086 
microprocessors. 

SM-ALC  is  monitoring  the  contractor's  development  of  a  software 
development  facility  (i.  e.  ,  an  ISF)  that  SM-ALC  will  use  to  meet  its 
software  support  responsibilities.  This  facility  is  scheduled  for 
delivery  in  January  1984.  When  operational  at  SM-ALC  the  facility 
will  have  the  capability  to  reprogram  both  MAR  software  and  firmware. 
Since  the  facility  is  not  scheduled  to  have  a  hot  mockup  MAR,  integration 
testing  will  have  to  be  conducted  at  an  operational  site. 

In  addition,  the  facility  will  not  be  able  to  simulate  the  Beacon 
Mission  Software.  Thus,  BMSW  changes  cannot  be  tested  in-house 
and  will  require  field  testing. 

When  operational,  the  support  facility  at  SM-ALC  will  incorporate 
fhe  following  computer  components  as  well  as  necessary  interface 
equipment. 

•  GE  FFP/DDP  target  computer 

•  DEC  PDP  11/70  host  processor 

•  Tektronix  8002  microprocessor  tab  with  TI  9900  (option) 

•  AMD  2900  microprocessor 

The  necessary  support  facility  software  will  include  two  basic 
software  packages  and  seven  Non-Functional  Software  (NFSW)  CPCI's. 
They  are  as  follows: 

•  GE  FFP/DDP  Computer  FORTRAN  Compiler 

•  Copies  of  the  six  FASW  CPCI  Programs 
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•  Data  Processor  FORTRAN  Compiler  NFSW 

•  DEC  PDP  11/70  NFSW 

•  Data  Processor  NFSW 

•  Digital  Board  Tester  NFSW 

•  TI  9900  NFSW 

•  AMD  2900  NFSW 

•  Intel  8086  NFSW 

Figure  4-3  has  been  prepared  to  illustrate  the  specific  com¬ 
ponents  of  the  SEEK  IGLOO  ISF. 

4. 2, 2. 2  Hardware  Support 

The  Alaskan  Air  Command  (AAC)  will  be  responsible  for 
organizational  and  intermediate  level  maintenance.  AFLC  will  be 
responsible  for  depot  level  maintenance  of  computer  resources.  All 
software  changes  will  be  accomplished  at  the  depot  level  at  SM-ALC. 
However,  the  final  stages  of  integration  testing  will  be  accomplished 
at  a  field  location  as  the  ISF  will  not  have  a  hot  mockup. 

Organizational  maintenance  shall  be  based  upon  remove  and 
replace  "on  equipment"  actions  at  the  Line  Replaceable  Unit  (LRU) 
level.  An  LRU  is  constructed  to  be  that  unit /module /subassembly 
which  is  a  self-contained  plug-in  unit  to  which  a  fault  can  be  isolated. 
All  LRU's  shall  be  readily  removable  without  disassembly  of  the 
next  higher  assembly;  i.  e. ,  unbolting,  unsoldering,  etc,  other  than 
disconnecting  of  cables  (coaxial,  cannon  plug,  or  strip  line  connectors). 
Organizational  maintenance  shall  be  within  the  capability  of  one  on-site 
crew  of  no  more  than  three  maintenance  personnel  trained  on  the 
equipment.  Organizational  maintenance  shall  be  assisted  by  an 
automated  monitoring  and  fault  isolation  system. 
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Figure  4-3.  SEEK  IGLOO  ISF  Components 


Intermediate  level  maintenance  shall  be  performed  either 
on- station  by  specialists  dispatched  from  Elmendorf  AFB  or  at  the 
Centralized  Maintenance  Facility  (CMF)  at  Elmendorf  AFB.  At  the 
CMF,  LRU's  will  be  repaired  using  appropriate  support  equipment. 

Depot  level  maintenance  shall  be  accomplished  either  on-station 
or  at  the  CMF  at  Elmendorf  AFB,  or  at  SM-ALC.  Depot  level  main¬ 
tenance  shall  include  those  tasks  beyond  the  capability  of  the  organi¬ 
zational  and  intermediate  level  maintenance  facilities. 

4.2.3  Support  Posture  Evaluation 

The  SEEK  IGLOO  ISF  is  to  be  developed  by  the  contractor  and 
delivered  to  SM-ALC.  The  current  schedule  calls  for  its  delivery  in 
January  1984.  If  the  SEEK  IGLOO  ISF  is  completed  according  to  cur¬ 
rent  specifications  it  will  provide  a  capability  that  is  sufficient  to  sup¬ 
port  all  of  the  SEEK  IGLOO  CPCI's.  However,  since  the  ISF  is  not 
scheduled  to  have  a  hot  mockup  radar  it  will  be  necessary  to  conduct 
final  verification  and  validation  of  software  changes  at  an  operational 
site.  The  procedures  for  changing  SEEK  IGLOO  computer  programs, 
screening  and  reviewing  these  change  requests  and  recommended  fixes, 
conducting  development  and  operational  tests,  and  distributing  CPCI 
changes  have  not  been  finalized. 

Table  4-3  presents  an  assessment  of  the  adequacy  of  the  planned 
SEEK  IGLOO  support  posture  when  compared  to  the  ECS  support 
requirements  presented  in  Section  2.  The  comments  are  grouped 
into  the  same  six  functional  areas  in  which  Section  2  has  grouped  the 
support  requirements. 

4.3  E-3  A  AW  ACS 

4.3.1  System  Description 

The  Airborne  Warning  and  Control  System  (AW ACS)  designated 
as  the  E-3A  aircraft  is  a  converted  Boeing  707-320.  It  is  configured 
with  the  latest  communications,  radar,  and  computer  equipment  and 
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Table  4-i.  SEEK  IGLOO  Support  Posture  Status 


Support  Requirements 

Findings /Remarks 

ECS  Change 

The  CRISP  adequately  describes  an  ISF 
capable  of  supporting  the  development  of 
ECS  changes.  This  facility  is  being 
developed  by  the  contractor  for  delivery 
in  1984.  Pending  delivery  and  installa¬ 
tion  of  the  ISF  and  completion  of  operator 
training,  CPCI  changes  will  be  made  by 
the  contractor. 

Change  Analysis  and 
Specification 

An  ISF  support  team  has  not  yet  been 
identified  nor  trained  to  support  the 
system.  The  required  training  is  des¬ 
cribed  in  the  CRISP. 

Engineering  Development 
and  Unit  T est 

When  operational,  the  ISF  will  provide 
a  means  for  integrating  software  changes 
into  the  overall  system.  All  modules 
can  be  tested  except  the  Beacon  software. 
CPCI  change  Y&V  requirements  should 
be  strengthened  in  the  CRISP. 

Systems  Integration 
and  Test 

The  planned  configuration  of  the  ISF  will 
allow  testing  of  both  MAR  software  and 
firmware.  However,  the  ISF  will  not 
have  a  hot  mockup,  therefore  final  soft¬ 
ware  integration  must  be  accomplished 
at  a  field  site.  Beacon  mission  software 
changes  will  also  require  field  inte¬ 
gration  testing.  CPCI  change  V&V 
requirements  should  be  reviewed  and 
strengthened. 

Change  Documentation 

The  O/S  CMP  has  not  been  published. 

Certification  and 
Distribution 

See  above. 

provides  a  surveillance  and  command  and  control  capability  for  tactical 
air  units.  Its  most  conspicuous  feature  is  a  30-foot  diameter  black 
and  white  radar  rotodome  sitting  atop  two  pylons  jutting  up  from  the 
rear  of  the  fuselage.  The  elliptical  dome  houses  a  specially  developed 
radar  capable  of  detecting  and  tracking  aircraft  more  than  250  miles 
away  at  all  altitudes  over  land  and  water  in  any  direction.  Its  avionics 
suite  enables  the  E-3A  to  perform  command  and  control  for  a  wide 
range  of  air  missions  including  air  superiority,  airlift,  reconnaissance, 
interdiction,  and  close  air  support. 

The  highly  complex  avionics  suite  incorporates  a  sophisticated 
computer  system  including  both  airborne  and  ground-based  elements. 

The  airborne  element  contains  four  computers:  an  IBM  4  it  CC-1 
which  serves  as  t!ie  central  data  processor,  a  Westinghouse  AN/AYK-8 
which  serves  as  a  radar  data  correlator,  a  Delco  Carousel  IV,  and 
a  Northrop  NDC  1070.  The  Delco  computer  is  part  of  the  inertial 
navigation  system  while  the  Northrop  computer  is  part  of  the  Omega 
navigation  system.  The  ground  support  element  is  currently  composed 
of  four  existing  hardware/software  systems  with  one  more  system  to 
be  added  that  is  presently  in  the  planning  stage.  The  four  systems  are 
the  IBM  370/155  large-scale  data  processor,  a  mission  simulator 
incorporating  a  modified  IBM  4  tt  CC-1,  an  individual  positional 
trainer  system  also  incorporating  a  modified  IBM  4  tt  CC-1,  and  a 
flight  simulator  built  around  a  Redifon  2000A  computer.  The  fifth 
ground-based  support  system  is  to  be  the  Avionics  Integration  Support 
Facility  (AISF). 

The  AW  ACS  system  is  one  of  several  C-E  systems  in  the  inventory 
that  will  be  supported  in  part  by  the  user  (in  this  case,  TAC)  and  in 
part  by  AFLC.  The  TAC  support  is  provided  by  the  552nd  AWACS 
Wing  while  the  AFLC  support  is  provided  by  the  acquisition  (MMA) 

«nd  «-ngineering  (MME)  divisions  of  OC-ALC. 


Table  4-4  presents  a  list  of  the  primary  AWACS  CPCI's  that 
require  software  support.  As  noted,  TAC  is  responsible  for  ten  of  the 
system's  major  CPCI's  while  AFLC  is  responsible  for  seven  CPCI's. 
Two  of  the  seven  CPCI's  are  in  the  OFP  category.  The  table  also 
indicates  the  operational  computer  in  which  each  CPCI  executes  and 
whether  the  program  is  airborne  or  ground-based. 

Among  the  airborne  computers  the  IBM  4  rr  CC-1  is  the  central 
on-board  computer,  and  uses  the  Airborne  Operational  Computer 
Program  (AOCP).  This  program  accepts  radar  and  na\igation  data 
input  from  the  radar  and  navigation  computers  to  help  the  mission  crew 
detect,  track,  and  identify  targets,  commit  and  control  weapons 
resources,  and  display  and  record  data.  In  addition,  system  main¬ 
tenance  and  in-flight  performance  programs  function  under  the  control 
of  the  AOCP,  monitoring  computer  hardware  operation  and  providing 
maintenance  information  to  the  on-board  computer  operator.  With 
the  ability  to  analyze  failures,  the  programs  automatically  switch  in 
redundant  equipment  or  alert  the  computer  operator  to  replace 
components. 

An  airborne  utility  program  provides  printouts  of  operational 
and  maintenance  information.  A  preflight  GO/ NO-GO  hardware  check 
of  the  computer  system  is  performed  by  a  pre-mission  readiness 
program.  More  comprehensive  fault  isolation  of  on-board  equipment 
is  provided  b /  the  aircraft's  diagnostic  maintenance  program. 

The  second  airborne  computer  system,  the  Westinghouse  Radar 
Data  Correlator  (RDC)  responds  to  command  signals  received  from 
the  airborne  operational  computer  program.  It  processes  radar 
target  data  for  use  by  the  operators.  A  built-in  fault  isolation  capability 
monitors  the  radar  hardware's  status. 

Rounding  out  the  airborne  element  are  the  Delco  Inertial  and  the 
Northrop  Omega  navigational  computers.  They  provide  the  E-3A's 
position  and  attitude  to  the  flight  crew,  radar,  and  airborne  opera¬ 
tional  computer  program. 
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supported  by  the  IBM  370/155. 


Among  the  ground-based  support  elements  of  the  system  the 
IBM  370/155  is  the  primary  support  computer.  A  370/155  resident 
ground  utility  program  supports  maintenance  of  the  operational  soft¬ 
ware  by  generating  master  tapes  for  the  4  tt  computer  and  preparing 
simulation  data  for  program  testing.  It  also  provides  display  back¬ 
ground  geography  and  generates  theater  unique  operational  information. 

A  systems  exercise  and  analysis  computer  program  generates  exercise 
tapes  for  testing  the  operational  program  and  for  training  personnel 
on-board  the  E-3A  or  in  the  mission  simulator.  The  program  also 
reduces  the  recorded  data  to  summarize  command  and  control  activities, 
give  exercise  results,  and  provide  a  weapons  utilization  summary  and 
other  operational  information. 

The  mission  simulator  computer  program  operates  in  a  modified 
IBM  4  tt  and  provides  training  for  E-3A  mission  crews.  Essentially, 
it  is  a  modified  version  of  the  Airborne  Operational  Computer  Program 
(AOCP),  but  in  addition  includes  instructor  provisions  and  total  simula¬ 
tion  of  IFF  and  navigation,  and  has  replay  capabilities.  The  simulator 
also  provides  a  means  for  limited  checkout  and  testing  of  the  AOCP. 

The  individual  positional  trainer  program  operates  in  another 
modified  IBM  4  tt  and  provides  realistic  training  for  individual  crew 
members  by  using  a  modified  version  of  the  AOCP  for  independent 
instruction.  This  trainer  is  operated  by  TAC  for  the  purpose  of 
qualifying  individual  mission  crew  members  in  the  performance  of 
duties  associated  with  data  display  and  control. 

The  flight  simulator  computer  program  which  executes  in  a 
Redifon  2000A  computer  is  an  advanced  version  of  other  Air  Force 
flight  crew  simulators.  Its  support  program  provides  real  time  com¬ 
putation  and  inputs  to  implement  major  aircraft  systems  in  a  simulation 
mode. 

The  E-3A  AW  ACS  AISF  is  currently  still  in  theplanning  and 
development  phase.  It  will  provide  the  necessary  mission  avionics. 


computers,  and  software  tools  to  allow  OC-ALC  to  organically 
maintain  their  assigned  E-3A  CPCI's.  Of  the  seven  CPCI's  that 
Table  4-4  indicates  AFLC  is  to  support,  six  are  to  be  supported  by 
the  AISF.  They  are  as  follows: 

•  Surveillance  Radar  CP 

•  Surveillance  Radar  Ground  Support  CP 

•  Navigation  CP 

•  Pre-Mission  Readiness  CP 

•  Diagnostic  Maintenance  CP 

•  System  Maintenance  CP  Fault  Trees 

•  The  Flight  Simulator  CP  is  a  self-supporting 

stand-alone  program  not  supported  in  the  AISF 

The  AISF- supported  computer  programs  are  briefly  described  in 
the  following  paragraphs. 

4.3. 1.1  Surveillance  Radar  Computer  Program 

The  Surveillance  Radar  Computer  Program  (SRCP)  executes  in 
the  E-3A  Westinghouse  Radar  Data  Correlator  (RDC).  The  RDC  con¬ 
sists  of  a  dual  processor  with  separate  core  program  memory  and 
MOS  data  memory,  a  special  handwired  processor  for  pulse  doppler 
range  resolution,  and  an  I/O  unit  for  communicating  with  the  radar 
subsystems  and  the  Interface  Adapter  Unit  (IAU).  The  SRCP  is 
organized  into  a  program  which  is  normally  resident  in  the  RDC  and 
a  fault  isolation  test  library  which  resides  off-line  on  magnetic  tape. 
The  SRCP  is  divided  into  three  major  functional  areas:  Data  Pro¬ 
cessing  and  Control  (DPAC),  Fault  Detection  (FD),  and  Fault 
Isolation  Test  (FIT). 

•  Data  processing  and  control  -  DPAC  software  provides 
the  specific  radar  functions  of  I/O  control  and  data 
sequencing,  data  memory  allocation  management,  mode 
control,  beam  stabilization,  main  beam  clutter  track¬ 
ing,  range  resolution,  correlation  of  radar  returns 
over  multiple  modulation  periods,  data  processing  for 
pulse  doppler  *nd  ECCM,  and  target  formatting. 


•  Fault  detection  -  FD  software  provides  continuous 
monitoring  of  various  GO /NO -GO  fault  indications  of 
the  radar.  Interleaved  tests  are  performed  to  diagnose 
faults  in  the  RDC  or  in  the  communications  links  with 
other  radar  subsystems.  Dedicated  time  tests  and 
manually  selectable  tests  provide  detailed  diagnosis 

of  radar  units.  The  FD  software  controls  execution 
of  all  tests  during  turn-on  and  normal  operation 
If  parameters  or  test  results  require  it,  the  FD 
software  controls  reconfiguration  of  the  radar  by 
switching  in  redundant  units. 

•  Fault  isolation  test  -  FIT  software  consists  of  detailed 
tests  to  isolate  radar  faults  to  replaceable  units  in 
major  radar  subsystem  elements.  These  tests 
normally  reside  off-line,  and  when  requested 
(manually  or  automatically)  they  are  loaded  into  the 
RDC.  In  general,  DPAC  routines  are  over-written 
and  reloading  of  the  resident  operational  program 
occurs  automatically  at  the  completion  of  FIT 
execution. 

The  SRCP  is  written  in  RDC  assembly  language  and  is  maintained 
by  use  of  the  Surveillance  Radar  Ground  Support  Computer  Program 
(SRGSCP). 

4.3. 1.2  Surveillance  Radar  Ground  Support  Computer  Program 

The  Surveillance  Radar  Ground  Support  Computer  Program 
(SRGSCP)  provides  the  support  software  needed  to  generate,  maintain, 
and  test  the  SRCP.  It  consists  of  the  following  functional  components: 

•  Program  Generation  Package  (PGP)  -  provides  the 
production  of  the  SRCP  tapes  and  maintenance  of  the 
radar  program  files.  Includes  the  RDC  assembler 
and  loader. 

•  RDC  Functional  Simulator  (RDCFS)  -  simulates  the 
RDC  processor  and  data  transfer  for  active  and 
passive  I/O  for  testing  the  SRCP  on  the  370/155. 

•  Radar  Data  Generator  (RDG)  -  generates  realistic 
radar  target  and  ECM  detection  data  from  a  scenario 
input  for  exercising  the  SRCP. 

•  Special  Test  Programs  (STP)  -  perform  octal  memory 
dump,  instruction  trace,  and  input  simulation  for 
testing  the  SRCP  on  the  RDC. 
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The  PGP,  RDCFS,  and  RDG  run  on  the  IBM  370/155  ground 
support  computer  and  are  written  mainly  in  FORTRAN.  The  STP 
operate  directly  on  the  RDC  and  are  written  in  RDC  assembly  language. 

4.3. 1.3  Navigation  Computer  Program 

The  Navigation  Computer  Program  (NCP)  consists  of  two  separate 
programs.  One  program  resides  in  the  Omega  Navigation  Equipment 
(ONE)  with  the  second  in  the  Inertial  Navigation  Equipment  (INE). 

The  ENE/NCP,  however,  will  not  be  covered  in  this  report  because 
the  system  will  be  maintained  by  DELCO  (Carousel  IV  is  used  by 
systems  other  than  E-3A).  In  this  report,  the  term  NCP  will  in  most 
cases  refer  to  the  ONE /NCP  which  is  resident  in  the  Northrop  NDC 
1070  computer. 

The  NCP  combines  data  received  by  the  Omega  receiver,  inertial 
data,  and  Doppler  velocity  data  in  a  Kalman  filter  to  provide  navigational 
data.  The  updated  navigational  data  is  used  by  the  AOCP  to  accurately 
reset  the  dual  INE, 

4. 3. 1.4  Pre-Mission  Readiness  Computer  Program 

The  Pre-Mission  Readiness  Computer  Program  (PMRP)  operates 
as  a  stand  alone  program  stored  in  mass  memory  and  is  loaded  into  the 
4  rr  CC-1  when  required.  It  performs  operational  GO /NO-GO  testing 
for  the  4tt  CC-1  computer  and  other  elements  of  the  data  processing 
functional  group  (excluding  the  IAU).  Outputs  from  PMRP  consist 
of  failure  indications  on  the  Operator  Control  Panel  (OCP)  and  a  printed 
summary  of  system  status,  either  a  GO  condition  or  a  system  NO-GO 
indication  with  failing  unit(s)  identified.  There  are  separate  versions 
of  the  PMRP  for  the  DPFG  and  for  the  IAU. 

4. 3. 1.5  Diagnostic  Maintenance  Program 

The  Diagnostic  Maintenance  Program  (DMP)  operates  as  a  stand 
alone  program  stored  in  mass  memory  and  is  loaded  into  the  4tt  CC-1 
when  required.  It  provides  for  a  detailed  logic  unit  test  with  fault 
isolation  of  the  elements  of  the  DPFG  in  a  pre-mission  environment. 

Two  separate  areas  are  the  data  processing  subsystem  DMP  and  the 
IAU  DMP. 
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4.3. 1.6  System  Maintenance  Computer  Program  Fault  Trees 

The  System  Maintenance  Computer  Program  (SMCP)  resident  in 
the  4tt  CC-1  operates  in  real  time  with  and  under  control  of  the  AOCP 
executive  to  provide  in-flight  operational  maintenance. 

The  fault  trees  are  part  of  the  monitor  and  test  subsystem  control 
function  of  the  SMCP.  This  SMCP  function  provides  for  performance 
monitoring,  fault  verification,  and  fault  isolation  of  mission  avionics 
hardware  [DPFG,  DDCFG,  IFG,  antenna  phase  controller,  monitor 
and  test  subsystem  (OBTM&M),  and  IAU  (fault  detection  only)].  Fault 
trees  consist  of  stored  information  (stored  on  the  MTT)  used  to  perform 
fault  isolation.  They  include  test  steps,  stored  limits  for  isolation  test 
points,  and  information  on  what  to  do  if  the  test  point  passes  or  fails. 
The  steps  are  continued  until  either  a  redundant  element  can  be  switched 
in  or  a  specific  repair  instruction  can  be  given  to  the  operator. 

4.3.2  Support  System 

4. 3. 2.1  Software  Support 

Responsibility  for  supporting  the  software  programs  that  reside 
in  the  E-3A  system's  embedded  computer  (both  airborne  and  ground- 
based)  is  shared  between  TAC  and  AFLC.  The  previous  section  has 
identified  the  individual  CPCI' s  to  be  supported  by  each  command. 

Of  particular  interest  to  this  study  are  the  six  CPCI' a  for  which  AFLC/ 
OC-ALC  is  responsible  and  the  A1SF  they  will  use  to  assist  them. 

The  AISF  is  defined  as  a  collection  of  software  support  tools 
assembled  in  ground  facilities  for  the  purpose  of  performing  the  steps 
requisite  to  implementing  changes  in  avionics  computer  programs. 
Existing  plans  call  for  it  to  be  developed  in  two  phases.  The  goal  of 
Phase  I  is  to  establish  a  limited  operational  support  capability  for 
assigned  software  on  core  aircraft  configurations  by  March  1983.  The 
goal  of  Phase  II  is  to  provide  a  full  software  operation  and  support 
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capability  for  the  core  configured  aircraft  with  a  limited  capability 
(surveillance  radar  and  navigation  systems  only)  for  the  Maritime 
(U.S.  Standard)  aircraft  configuration.  Plans  call  for  Phase  II  to  be 
completed  by  the  first  quarter  FY  84. 

The  AISF  will  be  comprised  of  equipment  (available  mainly 
from  existing  E-3A  facilities  and  the  aircraft  avionic  pipeline) 
integrated  with  minimal  departure  from  those  tools  employed  by  the 
developing  contractor  during  Full-Scale  Development  (FSD).  Installa¬ 
tion  will  be  in  a  Tinker  AFB  facility  specifically  constructed  for  soft¬ 
ware  support.  In  complying  with  AFR  800  series  management  policies, 
AISF  acquisition  will  subscribe  to  a  formal  design  cycle  with  attending 
configuration  management  procedures,  design  reviews,  and  audits. 

Four  primary  elements  will  form  the  AISF:  (1)  the  surveillance 
radar  AISF  module,  (2)  the  navigation  computer  system  AISF  module, 
(3)  the  data  processing  subsystem  AISF  module,  and  (4)  integration 
and  interface  special  equipment,  as  illustrated  in  Figure  4-4  and 
described  in  Table  4 -5. 

When  found  to  be  feasible,  government  assets  will  be  used  to 
configure  the  four  primary  AISF  modules.  Identification  of  some  of  the 
key  assets  follows. 

•  DPS  AISF  Module.  A  significant  amount  of  the  equipment 
required  for  this  module  can  be  made  available  from  the 
Software  Development  Laboratory  at  the  Boeing  Company's 
Seattle,  WA  facility.  The  remaining  equipment  will  be 
acquired  from  item  managers  and  through  procurement 
of  standard  commercial  equipment  and  services.  This 
module  will  provide  the  capability  to  support  the  follow¬ 
ing  CPCI's: 

s  Pre-mission  readiness  computer  program 

s  Diagnostic  maintenance  computer  program 

•  System  maintenance  compute  program  fault  trees 

s  SR  AISF  Module.  The  basic  approach  for  developing  this 
module  is  to  copy  the  test  stands  employed  by  the  radar 
contractor  (Westinghouse).  In-so-far  as  this  is  possible 
it  should  minimice  the  risks  of  a  new  design.  Significant 
cost  savings  may  result  if  all  or  portions  of  the  surveil¬ 
lance  radar  system  (No,  2001)  located  at  the  Westinghouse 
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Figure  4-4.  AISF  Elements 
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Table  4-5.  E-3A  AISF  Module  Equipment/Capability  Summary 
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Scientific  The  IBM  370  managed  and  operated  by  the  552nd  AW  AC  Wing  will  be  used  to 

Computet  aatiafy  off-line  scientific  batch  type  computing  requirements  which  accompany 

Support  the  AISF. 


facility  in  Baltimore,  MD  can  be  used.  Some  of  the 
components  and  subassemblies  of  this  system  can  be 
used  to  develop  the  Radar  Software  Bench  (RSB).  The 
RSB  represents  the  first  stage  of  the  SR  AISF  module. 

It  is  scheduled  to  be  operable  by  September  1981. 

The  second  stage  of  the  development  incorporates  the 
remaining  components  and  subassemblies  for  radar 
system  2001  including  those  components  previously 
supporting  enhancements  such  as  the  Spectral  Control 
Feature  (SCF).  This  composite  bench  (core  configura- 
ration)  is  scheduled  for  operation  by  January  1983. 

The  third  stage  of  development  provides  a  dual  con¬ 
figuration  bench  (Core /Maritime)  by  July  1984.  The 
additional  equipments  for  this  stage  can  be  provided 
from  Kit  No.  3  of  the  Maritime  Surveillance  Capability 
(MSC)  development  activity. 

The  SR  AISF  module  will  provide  the  capability  to 
perform  software  investigation/analysis  of  the  Detec¬ 
tion  Processing  and  Control  (DP AC)  portion  of  the 
surveillance  radar  computer  program  plus  initial 
support  of  the  Fault  Detect  (FD).  Special  Test(ST) 
portion  of  the  surveillance  radar  equipment.  The 
support  of  the  Fault  Isolation  Test  (FIT)  portions 
of  the  SRCP  will  be  limited  during  Phase  I. 

NCP  AISF  Module.  This  module  consists  of  an  Omega 
receiver  computer  (NDC  1070)  and  an  Inertial  Naviga¬ 
tion  Unit  (Carousel  IV)  configured  to  accurately  simulate 
the  E-3A  navigation  system.  An  HP  2113  minicomputer 
provides  the  trajectory  and  interface  functions  necessary 
to  create  a  real  time  operational  environment.  Acquisi¬ 
tion  of  this  module  will  be  as  indicated  by  the  following 
activities:  (1)  commercial  equipment  (standard 
peripherals)  will  be  acquired  under  the  auspices  of  the 
Naval  Air  Development  Center  (NADC)  to  acquire 
equipment  required  for  NCS  software  support  during 
full-scale  development/production,  (2)  E-2A  peculiar 
avionic  equipment  will  be  obtained  through  the  AFLC 
Item  Manager  (IM),  and  (3)  necessary  switching 
capability  and  cabling  will  be  acquired  through  NADC 
from  separate  vendor  contracts.  NADC  personnel  will 
assist  OC-ALC  personnel  to  install,  integrate,  and 
initially  check  out  the  NCS  AISF  module. 
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AISF  Integration  and  Special  Equipment.  The  DPS 
Module,  the  SR  Module  and  the  NCS  Module  need  to 
be  integrated  and  interconnected  to  produce  an 
integrated  software  support  facility.  The  special 
test  equipment  cabling,  interface  units,  and  so  forth 
that  are  required  will  be  procured  from  item  managers 
if  possible  or  from  commercial  sources,  if  necessary. 

4. 3. 2. 2  Hardware  Support 

The  maintenance  concept  to  be  utilized  for  the  E-3A  AISF  equip¬ 
ment  will  depend  on  whether  it  is  on-board  avionic  equipment,  com¬ 
mercially  available  equipment,  or  E-3A  AISF  unique  equipment. 

The  E-3A  AISF  equipment  which  is  identical  to  the  equipment 
on-board  the  E-3A  aircraft  will  be  maintained  as  if  it  were  another 
aircraft  with  spare  part  support  provided  by  the  appropriate  item 
manager.  The  same  maintenance  procedures  exercised  on  the  E-3A 
aircraft  itself  will  be  employed.  Existing  test  equipment  provided  for 
maintenance  of  the  E-3A  at  the  MOB  (TAFB)  will  be  used  with  main¬ 
tenance  assistance  provided  by  TAC  as  required. 

Commercially  available  peripheral  equipment  used  in  the  E-3A 
AISF  will  be  supported  through  maintenance  contracts  with  the  manu¬ 
facturer.  However,  in  certain  cases  it  may  prove  cost  effective  to 
directly  procure  spares  and  perform  organic  maintenance. 

Equipment  unique  to  the  E-3A  AISF  will  be  supported  by  main¬ 
taining  a  special  supply  of  spare  parts  purchased  from  the  vendor 
and  utilizing  organic  maintenance  technicians.  Spare  parts  in  this 
regard  will  be  ordered  and  maintained  in  accordance  with  the  procedures 
established  for  engineering  test  lab  equipment  acquisition. 

4.3.3  Support  Posture  Evaluation 

The  E-3A  AW  ACS  CPCI's  are  to  be  supported  by  two  commands, 
TAC  and  AFLC.  TAC's  software  support  facility  has  been  operational 
for  some  time  and  is  currently  supporting  the  CPCI's  that  have  been 
assigned  to  TAC.  AFLC's  OC-ALC  is  currently  in  the  early  stages 
of  developing  an  AISF  to  support  the  CPCI's  that  have  been  assigned 
to  AFLC. 
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The  TAC  facility  supports  the  E-3A's  Airborne  Operational 
Computer  Program  (AOCP)  which  resides  in  the  aircraft's  IBM  4tt 
CC-1  central  computer.  The  TAC  facility  also  will  support  several 
airborne  and  ground-based  support  and  test  computer  programs  when 
completed.  The  OC-ALC  ISF  will  support  the  airbone  surveillance 
radar  program,  the  airborne  Omega  navigation  program,  and  several 
support  and  test  computer  programs. 

If  the  OC-ALC  E-3A  AWACS  AISF  is  completed  as  currently 
planned,  it  will  provide  a  capability  sufficient  to  support  the  AFLC 
assigned  CPCI’s.  The  software  change  procedures  for  these  computer 
programs  relative  to  initiating  change  requests,  screening  and  review¬ 
ing  requests  and  recommended  fixes,  conducting  development  and 
operational  tests,  and  distributing  CPCI  changes  are  discussed  in 
detail  in  the  O/S  CMP.  However,  the  critical  OC-ALC  and  TAC  inter¬ 
faces  are  not  clearly  defined  in  the  O/S  CMP.  The  primary  emphasiB 
of  the  current  O/S  CMP  is  on  TAC  change  procedures.  AFLC  change 
procedures  should  be  strengthened  in  the  next  revision  of  the  O/S  CMP. 

Table  4-6  presents  an  assessment  of  the  adequacy  of  the  planned 
E-3A  AWACS  support  posture  when  compared  to  the  ECS  support 
requirements  presented  in  Section  2.  The  comments  are  grouped 
into  the  same  six  functional  areas  in  which  Section  2  has  grouped  the 
support  requirements. 

4.4  JOINT  SURVEILLANCE  SYSTEM 

4.4.1  System  Description 

The  Joint  Surveillance  System  (JSS)  is  presently  being  developed 
to  replace  the  SAGE/BUIC  system.  The  U.S.  and  Candian  mission  of 
peacetime  air  surveillance  and  control  of  sovereign  air  space  within 
the  Continental  United  States  (CONUS),  Alaska,  and  Canada  will  be 
accomplished  by  JSS.  For  Canada,  the  mission  is  expanded  to  include 
support  of  wartime  air  defense  functions,  and  in  Alaska  the  mission 
includes  the  performance  of  tactical  air  control  functions. 
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Table  4-6.  E-3A  AWACS  Support  Posture  Status 


Support  Requirements 

1 

Finding  •/ Remarks 

ECS  Change 

The  E-3A  AWACS  CPCI's  are  to  be  supported  in 
part  by  TAC  and  in  part  by  OC-ALC.  Thus,  when  a 
change  request  is  initiated  by  the  user  organisation 
it  must  first  be  ascertained  by  the  AWACS  CPCSB 
whether  TAC  or  OC-ALC  will  be  the  responsible 
organisation.  At  present  time  only  the  TAC  facility 
is  operational;  therefore,  any  changes  for  which 

AFLC  would  normally  be  responsible  are  presently 
handled  by  the  SPO /contractor  team. 

Change  Analysis  and 
Specification 

The  change  analysis  and  review  procedures  are 
clearly  defined  in  the  O/S  CMP  for  TAC  supported 
CPCI’s,  however  the  AFLC  review  process  is  not 
clearly  defined.  The  current  CRISP  and  O/S  CMP 
should  be  reviewed  and  updated. 

Engineering  Development 
and  Unit  Test 

The  currently  operational  TAC  software  support 
facility  at  Tinker  AFB  provides  the  capability 
required  to  Integrate  changes  to  the  CPCI's  for 
which  TAC  is  responsible.  The  facility  will  also 
support  development  testing.  CPCI  changes  for 
which  AFLC  is  to  become  responsible  at  PMRT 
are,  at  present,  handled  by  the  SPO  with  contractor 
support  in  contractor  facilities. 

System  Integration 
and  Test 

Both  the  existing  TAC  facility  and  the  upcoming 

OC-ALC  ISF  will  support  the  total  integration  and 
partial  operational  testing  of  E-3A  CPCI  changes. 

It  is  quite  likely  that  complete  verification  of 
software  changes  will  not  be  signed  off  until  the 

E-3A  aircraft  has  participated  in  a  flight  test  of 
the  changes. 

Change  Documentation 

AFR  800-14  prescribes  that  CPCI's  and  related 
documentation  be  assigned  a  CPIN  number.  TAC 
uses  a  unique  Software  Change  Report  (SCR) 
number  to  identify  each  CPCI.  Both  TAC  and 

OC-ALC  will  share  the  responsibility,  as  appro¬ 
priate,  for  maintaining  and  updating  the  E-3A 

AWACS  software.  The  joint  TAC /OC-ALC 
configuration  management  interfaces  should  be 
more  clearly  defined  and  strengthed  in  the  O/S 

CMP.  The  last  O/S  CMP  revision  was  in  May  1978. 

Certification  and 

Distribution 

The  using  command  change  distribution  procedures 
are  defined  in  the  O/S  CMP.  The  relationship  between 
these  procedures  and  TCTO  distribution  procedures 
required  in  AFR  800-14  for  AFLC  are  not  clear. 

This  relationship  should  be  spelled  out  in  an  O/S  CMP 
revision. 
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The  JSS  is  composed  of  three  major  and  unique  components. 

These  are  seven  individual  Region  Operations  Control  Centeres  (ROCC's), 
an  initial  complement  of  86  radar  sensor  sites  distributed  between  the 
ROCC's,  and  one  System  Support  Element  (SSE). 

4.4. 1.1  Region  Operations  Control  Centers 

Seven  ROCC's  will  provide  the  command,  control,  communications, 
and  surveillance  functions  for  JSS.  Each  will  include  Automatic  Data 
Processing  Equipment  (ADPE),  software,  displays,  and  communications 
necessary  to  sustain  these  functions.  Four  ROCC's  will  be  operated 
by  Aerospace  Defense  Command  (ADCOM)  and  located  in  the  CONUS; 
two  ROCC's  will  be  operated  by  the  Candian  Forces  and  located  in 
Canada;  and  one  ROCC  will  be  operated  by  Alaskan  Air  Command  (AAC) 
and  located  in  Alaska. 

4.4. 1.2  Sensors 

Initially,  the  86  sensor  sites  in  CONUS,  Alaska,  and  Canada 
will  provide  automated  surveillance  data  and  in  most  cases  height 
and  beacon  data  to  the  ROCC's.  The  system  will  allow  as  many  as 
140  sensor  sites  to  be  tied.  The  sites  will  contain  the  communications 
necessary  for  the  command  and  control  of  interceptor  aircraft. 

There  will  be  45  sensor  sites  in  the  CONUS  of  which  31  will  be 
joint  FAA/USAF  sites,  seven  will  be  USAF  only  site",  one  will  be 
joint  USAF/Navy,  five  will  be  FAA  data-tie  sites  (providing  search 
and  SIF  data  only),  and  one  will  be  an  aerostat  borne  radar  (SEEK 
SKYHOOK). 

Initially,  there  will  be  14  sensor  sites  in  Alaska,  one  of  which 
will  be  FAA  owned.  Two  sites  will  provide  data  to  a  ROCC  and  the 
FAA  ARTOC;  the  remaining  twelve  will  be  AAC  sites  providing  data 
to  the  ROCC.  Current  planning  for  future  expansion  of  radar  coverage 
in  Alaska  may  increase  the  number  of  sensor  site  inputs  to  a  total  of 
17  with  a  potential  for  20. 
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Initially,  24  existing  Canadian  sites  will  provide  data  to  two 
ROCC's  and  to  the  Ministry  of  Transport  Joint  Enroute  Terminal 
System  Control  Centers.  Current  planning  involves  the  replacement 
of  the  existing  24  radars  with  up  to  40  new  type  radars,  Canadian 
participation  in  JSS  is  limited  to  the  joint  US/Canadian  acquisition  of 
ROCC's  and  associated  training  and  support. 

4.4. 1.3  System  Support  Element 

The  System  Support  Element  (SSE)  segment  will  support  all 
ROCC/SSE  military-owned  computer  hardware  and  software,  displaced 
Southeast  ROCC  Operations  capability,  and  training  of  USAF/CF 
operations  and  maintenance  personnel  as  directed  by  HQ  USAF  and 
NDHQ.  The  SSE  segment  shall  consist  of  two  subsegments:  an  ROCC 
System  Support  Facility  (RSSF)  subsegment  whose  mission  will  be 
software  oriented  and  a  System  Hardware  Support  (SHS)  subsegment 
whose  mission  will  be  hardware  oriented.  These  two  subsegments 
shall  include  the  following  functional  areas: 

•  ROCC  System  Support  Facility  (RSSF)  subsegment 

Computer  Program  Functional  Area  (SCPFA) 

Data  Processing  and  Display  Functional  Area  (SDPDFA) 
Communications  Functional  Area  (SCFA) 

Support  Functional  Area  (SSFA) 

Facilities  Functional  Area  (SFFA) 

*  System  Hardware  Support  (SHS)  subsegment 

Computer  Program  Functional  Area  (HCPFA) 

Data  Processing  and  Display  Functional  Area  (HDPDFA) 
Communications  Functional  Area  (HCFA) 

Support  Functional  Area  (HSFA) 

Facilities  Functional  Area  (HFFA) 

4.4. 1.4  Computer  Resources 

The  computer  resources  within  a  JSS  ROCC  consist  of  the  multiple 
computer  and  associated  peripherals  shown  in  Figure  4-5.  The  figure 
illustrates  the  ROCC's  configuration  contains  two  complete  and 
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DATA  PROCESSING  SET  (DPS) - ►  j  — DISPLAY /OPERATIONAL  CONTROL  SET  (DOCS) 


complementary  threads  (or  paths)  from  the  ROCC  Communication 
Functional  Area  (RCFA)  through  the  Data  Processing  and  Display  Func¬ 
tional  Area(DPDFA)  to  the  operator  display  consoles.  In  effect,  the  top 
half  of  the  figure  represents  one  complete  data  processing  and  display 
path,  while  the  lower  half  represents  a  second  complete  path.  Each  of 
the  two  threads  through  the  ROCC  configuration  includes  four  computers. 
The  Central  Computer  (CC)  is  a  Hughes  H5118,  the  Programmable 
Peripheral  Computer  A(PPC-A)  is  an  AN/UYK-40,  the  PPC-B  is  also  an 
AN/UYK  with  two  disks  and  four  MTU's,  and  the  Display  Controller 
(DC)  is  also  an  AN/UYK-40  with  one  disk.  In  addition,  the  system 
control  console  which  is  shared  by  each  of  the  two  threads  includes 
one  more  AN/UYK-40.  The  system's  operator  display  consoles  do 
not  include  an  embedded  digital  computer,  but  they  do  include  five 
different  types  of  Printed  Circuit  Boards  (PCB'b),  each  with  multiple 
PROM's.  These  boards  are  classified  as  dynamic  firmware  and  must 
also  be  supported  by  the  Software  Support  Element  (SSE). 

As  mentioned  in  Section  4.4.1. 3,  the  Software  Support  Element 
(SSE)  contains  an  RSSF  subsegment  whose  mission  is  to  provide  soft¬ 
ware  support  and  a  SHS  subsegment  having  a  hardware  oriented  mission. 

The  RSSF  is  to  be  collocated  with  the  Southeast  (SE)  ROCC  at 
Tyndall  AFB,  FL.  Three  major  activities  shall  be  performed  by 
this  RSSF.  The  first  is  software  support  for  all  seven  ROCC's  and 
the  complete  SSE.  The  second  is  to  act  as  a  displaced  SE  ROCC  when 
required.  The  third  is  to  support  the  positional  training  of  ROCC 
operators. 

The  SHS  has  two  major  activities.  The  first  is  to  provide  hard¬ 
ware  maintenance  training  while  the  second  is  to  support  kit  proofing. 

Because  the  RSSF  must,  at  times,  operate  as  a  displaced  SE 
ROCC  it  must  have  the  same  operational  computer  prof  ca.n  CPCI's 
as  the  seven  ROCC's  will  have.  Thus,  the  RSSF  CPCI's  described 
below  include  the  ROCC  CPCI's. 
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4.4.1.  4.1  RSSF  Operational  CP  CPCI1  8 

•  Operating  System  Set  (OSS)  -  shall  include  all  computer 
programs  required  for  operations  control  task  manage¬ 
ment,  recover,  input /output  control,  and  system  con¬ 
fidence  necessary  to  perform  the  RSSF  mission. 

•  Applications  Set  (APS)  -  shall  include  all  computer 
programs  required  to  execute  and  control  real  time 
Displaced  Southeast  ROCC  Operations  (DISROP)  for 
the  southeast  region. 

•  Display  Control  Firmware  (DCF)  -  computer  program 
shall  support  efforts  to  reprogram  the  PCB's  in  the 
operator  display  consoles. 

4.  4.  1.  4.  2  RSSF  Support  CP  CPCI*  s 

•  Support  Set  (SUS)  -  shall  include  all  computer  programs 
required  for  language  processing,  utility  functions,  and 
data  reduction  necessary  to  support  the  RSSF  missions. 

•  System  Exercise  Set  (SES)  -  shall  include  all  computer 
programs  necessary  for  the  generation,  editing,  and  review 
of  non  real  time  simulation  data.  This  capability  shall 
provide  for  the  generation  of  large  scale  multi-region 
NORAD  exercise  files. 

•  Diagnostic  Set  (PIS)  -  shall  include  all  computer  programs 
required  to  support  fault  isolation  for  equipment  in  the 
RSSF  data  processing  and  display  functional  area  and 
selected  equipment  in  the  RSSF  subsegment  communica¬ 
tions  functional  area. 

•  Data  Reduction  Set  (DRS)  -  shall  include  all  computer 
programs  required  to  support  data  reduction  and  system 
evaluation  activities. 

•  System  Control  Set  (SCS)  -  shall  include  all  computer 
programs  required  to  support  system  control  activities. 

4.  4.  1.4.  3  SHS  Operational  CP  CPCI*  s 

•  Operating  System  Set  (OSS)  -  shall  include  all  computer 
programs  required  for  task  management,  resource  manage¬ 
ment,  input/output  control,and  on-line  fault  detection 
necessary  to  perform  the  SHS  mission.  Except  where 
limited  by  equipment  configuration, this  set  should  be 
identical  to  the  ROCC  OSS. 
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•  Applications  Set  (APS)  -  shall  include  all  computer 
programs  required  to  support  the  diagnostic  capability 
of  the  ROCC  Diagnostic  Set  for  hardware  maintenance 
training  and  kit  proofing.  It  shall  also  provide  for  the 
use  of  the  on-line  confidence  checking  capability  for 
training  purposes.  Except  where  limited  by  equip¬ 
ment  configuration,  the  operation  and  performance  of 
the  on-line  confidence  checking  capability  in  the  train¬ 
ing  environment  of  the  SHS  shall  be  identical  to  that  of 
the  ROCC  Applications  Set. 

4.  4.  1.4.  4  SHS  Support  CP  CPCI1  s 

•  Diagnostic  Set  (PIS)  -  shall  include  all  computer  pro¬ 
grams  required  to  provide  for  the  use  of  the  off-line 
fault  detection  and  fault  isolation  capabilities  for  train¬ 
ing  purposes.  Except  where  limited  by  equipment  con¬ 
figuration,  the  operation  and  performance  of  the  off¬ 
line  fault  detection  and  fault  isolation  capabilities  in 
the  training  environment  of  the  SHS  shall  be  identical 
to  that  of  the  ROCC  diagnostic  set. 

4.4.2  Support  System 

4.4.2. 1  Software  Support 

Software  support  for  all  the  software  CPCI's  that  execute  in  the 
various  computers  of  the  ROCC  will  be  accomplished  by  the  RSSF  sub- 
segment  of  the  SSE.  Since  the  RSSF  must  also  operate  as  a  displaced 
SE  ROCC  for  a  portion  of  each  month,  it  must  have  a  similar  hard¬ 
ware  and  software  configuration.  Section  4. 4. 1.4  indicated  that  the 
ROCC  configuration,  in  effect,  has  two  identical  threads  through  the 
system  (see  Figure  4-5).  The  RSSF  complement  of  hardware  includes 
equipments  that  are  identical  by  type  to  those  in  either  thread  of  an 
actual  ROCC,  but  not  identical  by  number.  For  example,  the  RSSF 
will  have  only  11  operator  display  consoles  while  the  ROCC  will  have 
14  in  each  thread.  The  specific  number  of  each  equipment  type  that 
constitutes  the  total  RSSF  configuration  is  listed  in  the  JSS  CRISP 
(Appendix  D3  and  D4)  and  will  not  be  repeated  here. 
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The  RSSF  will  be  required  to  support  three  major  activities. 

The  first  is  software  support  which  shall  be  shared  with  the  SE  ROCC. 
The  RSSF  shall  be  manned  and  equipped  to  provide  all  software  support 
required  by  the  seven  ROCC's  and  the  SSE.  This  shall  include  the 
capability  to  design,  modify,  and  test  computer  programs.  It  shall 
also  include  the  capabilities  to  support  storage  media  (e.g.,  magnetic 
discs  and  tapes),  documentation,  a  computer  program  support  library, 
generation  of  exercise  files  for  both  single  region  and  multi-region 
exercises,  and  replaying  an  event  after  the  fact. 

The  second  activity  is  Displaced  Southeast  ROCC  Operations 
(DISROP).  The  DISROP  activity  shall  be  activated  when  it  becomes 
necessary  to  use  the  SE  ROCC  resources  to  support  certain  system 
capacity  and  operational  ROCC  software  test  and  evaluation  activities. 
Under  these  circumstances,  SE  ROCC  operations  personnel  shall 
relocate  temporarily  to  the  RSSF  and  conduct  DISROP  using  RSSF 
capabilities.  The  requirement  to  use  SE  ROCC  resources  for  system 
testing  shall  be  minimized.  It  is  anticipated  that  no  more  than  36  hours 
per  month  of  the  SE  ROCC  operating  time  will  be  used. 

The  third  activity  is  training.  One  of  the  most  important  training 
activities  shall  be  positional  training  of  ROCC  operators.  This  shall 
be  ROCC  oriented  training  for  operational  personnel  who  have  completed 
basic  Air  Training  Command  courses.  Operator  training  will  be  shared 
with  the  SE  ROCC  as  determined  by  operational  procedures.  Training 
will  include  computer  operators  (CpOp)  and  computer  programmers. 
Selected  portions  of  computer  operator  training  may  be  at  the  SHS 
subsegment  or  the  RSSF.  Training  may  be  accomplished  on  equipment 
mockups  if  the  mockups  meet  training  requirements. 

The  operational  and  support  CPCI's  that  will  execute  in  the  RSSF's 
computers  have  previously  been  identified  in  Sections  4.  4.  1. 4.  1  and 
4.  4.  1.  4.  2. 


4.4. 2. 2  Hardware  Support 

Hardware  support  of  ROCC  equipment  will  be  accomplished  by 
the  SHS  subsegment  of  the  SSE.  The  SHS  will  support  the  training 
of  hardware  maintenance  personnel  and  kit  proofing.  The  maintenance 
personnel  will  be  trained  in  the  use  of  ROCC /SSE  off-line/on-line 
diagnostic  computer  programs.  Kit  proofing  shall  include  hardware 
modifications  to  ROCC/RSSF  equipments  and  shall  include  verification 
of  equipment  operation  and  maintenance  technical  orders  and  changes 
thereto.  Equipment  kit  proofing,  modification  acceptance  testing, 
and  technical  order  verification  will  be  conducted  by  Air  Force 
Logistics  Command,  NDHQ,  and  the  using  agencies.  If  communications 
equipment  is  bought  rather  than  leased,  then  communications  maintenance 
training  may  be  located  at  the  SHS  subsegment. 

The  operational  and  support  CPCI's  that  will  execute  in  the  SHS's 
computers  have  previously  been  identified  in  Sections  4.  4.  1.  4.  3  and 
4.  4.  1.4.  4. 

4.4.3  Support  Posture  Evaluation 

The  JSS  RSSF  is  to  be  located  at  a  JSS  operational  site,  the  ROCC 
at  Tyndall  AFB,  FL.  As  a  support  facility  it  is  unique  that  it  will  also 
serve  as  a  back-up  ROCC  and,  in  addition,  will  be  used  as  a  training 
device  for  operational  and  maintenance  personnel.  The  RSSF  is  still 
in  the  development  stage;  however,  when  it  is  completed  it  will  be 
able  to  support  all  of  the  JSS  CPCI's.  ADCOM  (ADTAC)  configuration 
control  procedures  as  outlined  in  AFR  800-14  (Volume  II)  and  ADCOMR 
55-111  will  be  followed  during  the  software  change  process  in  order 
to  maintain  a  well -controlled  baseline.  These  procedures  will  be 
defined  in  the  O/S  CMP  when  it  is  written.  The  draft  CRISP  establishes 
the  O/S  CMP  as  the  principal  source  document  for  change  control. 

Table  4-7  presents  an  assessment  of  the  adequacy  of  the  planned 
JSS  support  posture  when  compared  to  the  ECS  support  requirements 
presented  in  Section  2.  The  comments  are  grouped  into  the  same  six 
functional  areas  in  which  Section  2  has  grouped  the  support  requirements. 
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Table  4-7.  JSS  Support  Posture  Status 


Support  Requirements 


Finding  s  /Remarks 


ECS  Change 


Operational  CPCI  will  be  supported  by  ADTAC 
(formally  ADCOM).  The  static  firmware  will 
be  supported  by  SM-ALC.  The  resources 
required  to  support  ADTAC  tasks  are  adequately 
described  in  the  CRISP;  however,  resources 
required  to  support  the  SM-ALC  assigned 
responsibilities  are  not  specifically  identified. 


Change  Analysis 
and  Specification 


The  current  CRISP  does  not  require  AFLC 
participation  in  the  change  analysis  process  for 
ECS  software  or  dynamic  firmware.  Static 
firmware  change  procedures  are  not  presented 
in  the  CRISP. 


Engineering  Development 
and  Unit  Test 


See  above. 


System  Integration 
and  Test 


The  JSS  RSSF  configuration  is  comprised  of 
components  that  are  identical  to  those  in  an 
actual  operational  site  and,  as  well,  duplicate 
a  complete  processing  thread  through  a  site 
from  the  communications  interface  to  the 
operator  display  consoles.  Thus,  the  facility 
is  capable  of  achieving  100  percent  verification 
of  CPCI  changes. 


Change  Documentation 


The  document  and  configuration  management 
requirements  are  called  out  in  the  draft  CRISP. 
This  document  and  the  O/S  CMP,  when  it  is 
written,  will  act  as  a  configuration  control 
MOA  between  the  employing  and  supporting 
commands.  Specific  documentation  procedures 
will  be  spelled  out  in  the  O/S  CMP 


Certification  and 
Distribution 


Basic  requirements  have  been  established  In 
the  draft  CRISP,  however,  more  detailed  pro¬ 
cedures  should  be  included  in  the  O/S  CMP. 


4.5  JOINT  TACTICAL  INFORMATION  DISTRIBUTION  SYSTEM 

4.5.1  System  Description 

The  JTIDS  program  capitalizes  upon  the  experience  and  technology 
established  through  previous  developments  of  the  individual  services 
both  in-house  and  within  industry.  The  program  was  established  to 
converge  previous  and  on-going  efforts  into  a  common  joint  service 
capability.  This  is  possible,  since  standardization  of  the  JTIDS  pulse, 
RF,  and  coding  characteristics  has  made  all  JTIDS  development  efforts 
complementary  and  has  established  multiple  sources  within  industry 
for  most  of  the  critical  long-lead  hardware  and  software  elements. 

A  secure  data  unit  is  being  developed  and  procured  by  the  National 
Security  Agency  for  use  with  all  JTIDS  terminals.  A  common  JTIDS 
language,  TADIL  J,  is  being  developed  by  the  Joint  Interoperability 
of  Tactical  Command  and  Control  Systems  (JINTACCS)  program.  The 
JTIDS  program  is  designed  to  develop  and  acquire  a  time  division 
multiple  access,  secure,  jam-resistant,  low  intercept  potential,  digital 
information  distribution  system  with  relative  navigation,  and  positive 
user  identification  capabilities  suitable  for  use  by  all  services,  JTIDS 
is  planned  to  be  used  within  a  mix  of  alternative  communications 
resources  to  interconnect  the  tactical  and  air  defense  elements  of  all 
services  including  surface  and  airborne  command,  control,  sur¬ 
veillance  and  intelligence  centers,  ships,  and  combat  and  support 
aircraft. 

Four  types  of  terminals  are  eventually  envisioned  for  the  total 
system.  Brief  descriptions  follow. 

4. 5. 1.1  Class  1  Terminal 

This  terminal  is  being  developed  by  Hughes  Aircraft  and  is  often 
referred  to  as  the  Hughes  Improved  Terminal  (HIT).  It  is  a  high 
powered  terminal  for  use  in  large  platform  aircraft  (e.g. ,  E-3A),  ships, 
and  ground  tactical  communications  systems.  The  HIT  (AN/URQ-31) 
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is  a  terminal  consisting  of  both  hardware  and  computer  program  software 
which  will  provide  the  capability  for  any  equipped  platform  to  participate 
in  the  JTIDS.  The  terminal  provides  the  capability  to  transmit  in 
assigned  time  slots  within  the  network  structure  and  to  receive  in  all 
time  slots  not  used  for  transmission.  The  HIT  operates  in  a  frequency 
band  between  960  and  1215  MHz  with  a  maximum  range  of  500  nautical 
miles. 

A  relative  navigation  capability  is  being  developed  for  potential 
use  by  Class  1  equipped  systems.  This  effort  is  a  software  modification 
to  the  basic  HIT  computer  program.  Relative  navigation  will  provide 
the  user  with  geodetic  and  relative  navigation  capabilities  with  high 
accuracy.  In  addition  to  software  modifications,  hardware  additions 
will  be  required  to  interface  the  HIT  terminal  software  with  the  par¬ 
ticular  platform  to  be  installed. 

4.  5. 1.2  Class  2  Terminal 

The  Class  2  Terminal  is  a  smaller,  lower  powered  version  of 
the  Class  1  Terminal  designed  for  space  limited  platforms  such  as 
flighter  aircraft  (e.g.,  F-16  and  small  ships).  The  Class  2  Terminal 
will  also  have  an  integrated  tactical  air  navigation  and  relative 
navigation  capability.  The  Class  2  Terminal  is  currently  in  the  source 
selection  process  and  will  not  be  discussed  in  any  detail  in  this  section. 

4. 5. 1.3  Class  3  Terminal 

The  Class  3  Terminal  will  be  a  low  cost,  compact  terminal 
intended  for  guided  missile  control,  manpacks,  ground  vehicles,  and 
similar  applications.  It  is  still  in  a  very  early  concept  formulation 
stage. 

4.  5. 1.4  Adaptable  Surface  Interface  Terminal 

This  fourth  terminal,  the  ASIT,  will  provide  a  transparent  inter¬ 
face  with  existing  ground  command  and  control  systems.  It  provides 
a  jam  resistant  communication  link  between  JTIDS  users.  The  ASIT 
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program  is  developing  unique  hardware  and  software  along  with 
incorporating  a  GFE  Hughes  Improved  Terminal  (HIT)  with  an  IBM  ML-1 
translator/processor.  This  terminal  will  convert  the  TADIL  B  message 
standard  of  the  host  platform/system  into  JTIDS Interim  JTIDS  Message 
Specification  (IJMS)  and  vice  versa.  IBM  is  currently  under  contract 
to  develop  this  terminal. 

The  computer  resources  within  the  JTIDS  system  consist  of  the 
digital  computers  and  their  associated  CPCI's  that  are  embedded  in 
the  JTIDS  terminals.  The  Class  2  and  Class  3  Terminals  are  not 
included  below  for  previously  stated  reasons. 

4.  5.  1.5  E-3A/HIT,  Class  1  Terminal 

The  heart  of  this  terminal  is  a  Hughes  HMP  1116  16-bit  mini¬ 
computer  modelled  after  the  Interdata  7/16  minicomputer.  For  its 
E-3A  application  it  will  have  two  operational  CPCI's.  The  first  of 
these  is  the  E-3A/HIT  Operational  Computer  Program  (OCP).  This 
program  provides  the  interface  between  the  E-3A  and  the  JTIDS  net¬ 
work.  The  second  CPCI  is  the  HIT  Fault  Isolation  Software  (FIS). 

The  FIS  program  is  used  to  isolate  problems  within  the  terminal 
equipment. 

4.  5.  1.6  Adaptable  Surface  Interface  Terminal 

This  terminal  incorporates  a  complete  HIT  and  an  IBM  ML-1 
translator  processor  computer.  There  are  four  CPCI's  associated 
with  the  two  computers.  The  ASIT  HIT  has  its  own  unique  OCP.  This 
program,  referred  to  as  the  ASIT  Communications  Equipment  (ACE) 
OCP,  has  some  common  sub-programs  with  the  E-3A/HIT  OCP 
(about  45  percent),  but  the  remainder  is  distinctly  different.  A 
second  ACE  OCP  is  also  to  be  developed.  This  OCP  will  incorporate 
a  RELNAV  modification  to  the  original  ACE  OCP  to  allow  the  ground- 
based  ASIT  to  know  the  precise  location  of  each  E-3A  on  its  net.  The 
third  CPCI  is  the  OCP  for  the  ML-1  computer.  This  TP  OCP  resides 
in  the  ML-1  and  controls  the  ASIT  subsystems  for  translation  of  JTIDS 
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messages  to  TADIL-B  and  vice  versa.  The  fourth  CPCI  that  executes 
in  the  ASIT  is  the  TP  FIS  program.  This  program  resides  in  the 
ML-1  and  is  used  to  isolate  problems  within  the  terminal  equipment. 

4.5.2  Support  System 

The  JTIDS  computer  resources  support  system  encompasses 
multiple  organizations  and  two  distinct  time  periods.  Prior  to  PMRT, 
the  support  responsibility  has  been  delegated  by  AFSC  to  the  JTIDS 
Joint  Program  Office  under  the  Deputy  for  Communications  and 
Information  Systems,  at  ESD.  During  this  time  period  all  changes 
to  CPCI's  will  be  implemented  by  the  individual  contractors  using 
their  own  in-house  development  facilities.  Post-PMRT  will  find 
AFLC/WR-ALC  responsible  for  both  the  HIT  and  ASIT  computer 
resources  with  the  following  exception.  A  current  MOA  between  TAC 
and  AFLC  has  assigned  support  responsibility  for  the  ASIT /TP  OCP 
CPCI  to  TAC,  Langley  AFB. 

During  the  post-PMRT  time  period,  it  may  be  necessary  to  coordi¬ 
nate  a  software  change  with  the  552nd  AW  ACS  Wing  at  Tinker  AFB. 

This  situation  could  arise  if  a  proposed  change  to  a  CPCI  residing  in 
the  E-3A  HIT  affected  the  interface  between  the  E-3AHIT  and  the  E-3A 
on-board  IBM  4tt  CC-1  computer.  In  a  similar  manner,  TAC/Langley 
could  be  involved  if  a  proposed  change  affected  the  ASIT  toTACS/TADS 
interface.  As  a  result  of  these  complexities  it  is  apparent  that  the 
proper  configuration  control  of  proposed  changes  is  a  difficult  problem. 
Currently,  no  set  of  procedures  has  been  defined.  The  JTIDS  draft 
CRISP(s)  have  not  yet  been  coordinated  and  signed.  Furthermore,  the 
JTIDS  O/S  CMP  which  will  detail  the  interfaces  and  CM  procedures 
has  yet  to  be  written.  Thus,  any  specific  discussion  of  CM  procedures 
must  be  deferred.  On  the  other  hand,  significant  progress  has  been 
made  in  terms  of  designing  the  ISF  that  will  be  developed  at  WR-ALC 
to  provide  a  means  for  implementing  software  changes.  The  following 
section  will  describe  the  ISF  concept  in  some  detail. 
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4. 5. 2.1  Software  Support 

WR-ALC/MMEC  is  developing  an  implementation  plan  for 
acquiring  an  ISF  to  be  used  in  supporting  the  JTIDS  CPCI's  assigned 
to  WR-ALC.  The  ISF  consists  of  a  number  of  computer  based  simulators, 
several  actual  operational  terminals  (both  HIT's  and  ASIT's),  additional 
off-line  computing  equipment,  and  other  support  equipment.  In  addition 
to  the  ISF' 8  hardware  there  is  a  substantial  amount  of  operational, 
support,  and  test  software  to  be  developed.  The  following  sections  will 
describe  both  the  ISF  equipment  and  software  programs  in  some  detail. 

4.  5. 2. 1.1  ISF  Description.  Figure  4-6  is  presented  to  illustrate  the 
functional  configuration  of  the  WR-ALC  ISF.  At  the  present  time, 
the  only  planned  application  for  the  Class  1  HIT  terminal  is  the  E-3A 
while  the  only  current  application  of  the  ASIT  terminal  is  the  TACS/ 

TADS  system.  Thus,  as  key  elements,  the  WR-ALC  ISF  will  contain 
both  a  TACS/TADS  simulator  and  an  E-3A  simulator.  The  figure  also 
indicates  the  functional  layout  of  the  Langley  AFB  facility  and  the 
E-3A  AW  ACS  facility  at  Tinker  AFB,  as  well  as  their  interconnectivity. 
This  interaction  will  enable  testing  of  some  JTIDS  capabilities  which  a 
single  facility  is  incapable  of  performing.  It  will  allow  the  use  of  the 
facilities  during  Follow-on  Testing  and  Evaluation  (FOT&E)  after 
initial  software  turnover.  This  land  line  link  will  utilize  the  capabilities 
presently  existing  in  the  ASIT  to  pass  data  from  one  facility  to  another. 

The  functional  role  played  by  each  of  the  major  elements  of  the 
WR-ALC  ISF  and  the  other  two  facilities  follows. 

•  JTIDS  System  Exerciser  (JSE).  This  device  was  initially 
developed  to  support^he  Initial  Operational  Test  and 
Evaluation  (IOT&E)  tests  of  the  Adaptable  Surface  Interface 
Terminal  (ASIT).  It  is  capable  of  generating  or  recreating 
scenarios,  fully  loading  the  net,  and  providing  a  dynamic 
operator  interface  to  the  net  during  operation.  The  JSE 
incorporates  a  HIT  in  which  either  the  E-3A/HIT  OCP  or 
the  ACE  OCP  can  be  executed,  depending  upon  which  one 
is  desired  for  the  test  being  conducted. 
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»  TACS/TADS  simulator.  This  device  will  be  used  to 
exercise  the  ASIT  in  a  T ACS/TADS  environment.  The 
simulator  is  basically  a  protocol  and  message  traffic 
simulation  device.  It  also  has  a  scenario  generator 
with  which  it  will  be  possible  to  recreate  actual 
failure  conditions. 

The  WR-ALC  implementation  of  this  device  is  called 
the  Interface  Simulation  Analyzer  (ISA).  It  is  hosted 
in  a  Data  General  NOVA  3D  minicomputer.  The 
simulator  will  provide  the  means  to  support  the  ASIT 
Bus  Interface  Module  (BIM)  firmware  and  ensure  the 
interoperability  of  the  ASIT  with  the  JTIDS  net.  The 
TADIL  B  land  lines  will  provide  the  TADIL  B  message 
traffic  to  the  ASIT  surface  subscriber  interface. 

This  will  provide  means  for  live  validation  and 
verification  of  any  changes  to  the  firmware  in  the 
BIMS. 

•  E-3A  simulator.  This  device  is  hosted  in  a  Data 
General  Eclipse  S/200  minicomputer.  Basically  a 
message  protocol  and  data  flow  simulator,  the  E-3A 
simulator  also  has  a  scenario  generator  which  allows 
the  creation  of  alternate  testing  conditions.  It  will  be 
functionally  similar  to  the  device  developed  by  the 
E-3A  contractor  to  use  in  performing  acceptance  tests 
of  HIT  terminals  received  from  the  HIT  contractor. 
WR-ALC' s  implementation  of  this  device  is  called 

the  TDMA  Message  Processor  (TMP).  It  will  support 
electrical  testing  of  the  hardware  interface  between 
the  on-board  HIT  and  the  rest  of  the  E-3A  system. 

It  will  also  support  operational  testing  of  the  software 
interface  between  the  HIT  OCP  and  the  Data  Analysis 
Programming  Group  (DAPG)  software  package  that 
resides  in  the  E-3A's  on-board  central  computer 
(IBM  4tt  CC-1). 

•  Jamming  simulator.  This  device  will  be  required  on 
a  day-to-day  basis  when  developing  new  enhancements 
or  correcting  problems.  Therefore,  a  small  jammer 
simulator  will  be  required  in  the  lab  for  continuous 
interfacing.  Before  a  block  change  or  enhancement 
may  be  released  to  the  field,  it  must  be  verified  against 
enemy  EW  capabilities  as  simulated  by  this  device. 

•  Lab  net.  The  lab  net  is  expected  to  be  a  coaxial  type 

of  interface  to  eliminate  RF  radiation  inside  the  facility. 
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•  Other  support  equipment.  There  are  two  other  key 
support  elements.  The  first  is  the  test  and  maintenance 
support  station.  It  functions  as  a  test  and  simulation 
device  for  the  HIT  Transceiver  Processor  Unit  (TPU). 

It  also  provides  an  operator  the  flexibility  to  perform 
the  following  operations  with  a  bench-mounted  TPU 

or  with  TPU's  installed  in  HIT  racks. 

•  TMSS  self-test  diagnostics  are  used  to  verify  the 
operational  status  of  the  TMSS  HMP  1116  computer 
and  the  associated  peripherals.  The  diagnostics 
are  loaded  from  the  Magnetic  Tape  Unit  (MTU)  into 
the  HMP  1116  and  include  HMP  1116  memory, 
processor  and  serial  cham.J  tests,  and  peripheral 
tests  for  the  line  printer,  card  reader,  I/O 
terminal,  and  MTU. 

•  The  Communications  Processor  (CP)  of  the  TPU 
can  be  tested  using  the  same  HMP  1116  or  the 
PTU  CP  to  the  expansion  chassis  and,  thus,  to 
the  peripherals.  A  Processor  Maintenance  Panel 
(PMP)  provides  access  and  control  of  the  CP  and 
allows  the  processor  and  memory  diagnostics  to 
identify  faults  in  the  CP. 

•  Terminal  and  network  simulation  and  demonstration 
can  be  conducted  using  the  TMSS  as  a  signal  pro¬ 
cessor  simulator  with  special  software. 

The  second  is  the  Software  Maintenance  Facility  (SMF). 
The  primary  purpose  of  this  HMP  1116  hosted  facility 
is  to  provide  the  support  and  diagnostic  programs 
necessary  for  the  development  and  maintenance  of  the 
E-3A/HIT  OCP.  In  conjunction  with  support  software, 
the  SMF  provides  to  the  operator  the  following  functions: 

•  SMF  self-test  diagnostics  which  will  be  used  to 
verify  the  operational  status  of  the  HMP  1116 
computer  and  the  associated  peripheral  equipment 

•  Software  program  development  and  assembly 
p  Software  program  editing  and  debugging 

p  Load  tape  generation 

•  Test  data  reduction 

•  Off-line  equipment.  WR-ALC's  ISF  will  have  three 
computers  that  operate  in  an  off-line  mode  in  their 
support  role.  They  are  an  IBM  4331,  an  Interdata  8/32, 
and  a  microprocessor  support  lab. 
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•  Langley  AFB  facility.  Langley  is  the  location  of  the 
Tactical  Systems  Interoperability  Support  Center  (TSISC). 
This  gives  them  the  capability  of  simulating  two  TACS/ 

TAOS  elements  with  full  capabilities.  This  simulation 
capability  has  a  two-fold  purpose.  The  first  is  to  sup¬ 
port  the  TACS/TADS  elements'  software  and  the  second 
is  to  support  the  Joint  Interoperability  Tactical 
Systems  (JINTACCS)  interoperability  testing.  Through 
the  JTIDS  TAC/AFLC  memorandum  of  agreement  the 
Langley  facility  is  tasked  with  supporting  the  ASIT 
Translator  Processor  OCP  (TPOCP). 

The  two  TACS/TADS  element  simulators  already  exist 
as  does  the  off-line  support  computer,  an  IBM  370. 

Therefore,  the  only  additional  elements  required  for 
supporting  the  ASIT  TPOCP  and  the  associated  JINTACCS 
interoperability  testing  are  two  ASIT's  complete  with 
HIT'S,  a  coaxial  net  interface,  and  land  line  interfaces 
to  other  facilities  for  FOT&E. 

•  552nd  AW  ACS  Wing  facility.  This  facility  exists  and  is 
used  to  support  the  E-3A  mission  software.  A  JTIDS 
addition  to  this  facility  is  required  to  ensure  that 
changes  and  enhancements  to  the  JTIDS  terminal  are 
compatible  with  the  E-3A  interface  changes  and  enhance¬ 
ments,  The  ASIT  provides  a  land  line  link  to  the 
Langley  facilities  for  JINTACCS  testing  as  well  as  for 
FOT&E  uses. 

To  support  this  testing,  HIT' s  are  required  to  interface 
the  mission  simulators  and  the  trainer  (DDTS)  to  the 
coaxial  net.  The  ASIT  terminal  is  required  to  establish 
the  land  line  link  to  the  Langley  facility  for  JINTACCS 
interoperability  testing  and  FOT&E  uses. 

4.  5. 2. 1.2  Software  Program  Descriptions.  As  is  the  case  with  many 
C-E  systems,  the  software  programs  associated  with  JTIDS  can  be 
grouped  into  three  categories.  These  are  operational  software, 
support  software,  and  test  software.  The  software  programs  within 
each  of  these  three  categories  are  described  in  the  following  paragraphs 
for  both  the  Class  1  HIT  terminal  and  the  ASIT  terminal. 
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Class  1  (HIT)  Software  Description. 

HIT  Operational  Software.  The  Class  4  (HIT)  software  is  comprised 
of  three  distinct  functional  categories:  Operational  Computer  Program 
(OCP),  support  software,  and  test  software.  These  categories  are 
depicted  in  the  HIT  software  classification  tree  of  Figure  4-7. 

The  HIT  OCP  is  the  computer  program  which  resides  in  the 
Communication  Processor  (CP)  component  of  the  Transceiver  Pro¬ 
cessor  Unit  (TPU).  The  TPU  is  the  heart  of  the  HIT  and  serves  to 
control  the  HIT  subsystems  and  peripherals.  There  are  two  versions 
of  the  HIT  OCP.  One  is  called  the  ASIT  Communication  Equipment 
(ACE)  OCP  which  resides  in  the  HIT  used  with  the  ASIT  for  ground 
sites.  The  other  is  the  E -3  A /HIT  OCP  which  resides  in  the  HIT  used 
on  the  E-3A  aircraft. 

The  principal  operational  capability  of  the  HIT  OCP  is  to  establish, 
maintain,  and  control  communications  between  the  user  interfaces 
and  the  Joint  Tactical  Information  Distribution  System  (JTIDS)  network. 
The  JTIDS  network  consists  of  one  or  several  nets  (multi-net)  with 
one  terminal  operating  in  master  mode  for  all  nets  and  one  or  more 
terminals  operating  in  normal,  polling,  or  radio  silent  modes,  as 
participants. 

The  establishment  of  communication  between  the  user  terminal 
and  the  JTIDS  network  occurs  when  the  time  used  by  the  OCP  and  the 
time  used  by  the  JTIDS  network  are  the  same  (within  certain  tolerances). 
Because  a  master  terminal  defines  the  time  used  in  the  network,  it  is 
synchronization  and  therefore  has  established  communication  with  the 
network  as  soon  as  the  operator  has  entered  time.  For  all  other 
terminals  this  synchronization  must  be  achieved  over  three  distinct 
steps:  net  entry,  coarse  synchronization  and  fine  synchronization 
using  one  of  two  methods  of  synchronization,  and  Passive  Timing  (PT) 
or  Round  Trip  Timing  (RTT). 
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Figure  4-7.  HIT  Software  Classification  Tree 


During  initial  net  entry  a  terminal  uses  the  time  plus  time 
uncertainty  estimate  entered  by  the  operator  to  listen  to  network 
activity  occurring  in  prespecified  time  slots  and  prespecified  nets. 

Once  an  error-free  message  has  been  received  in  any  one  of  the  pre¬ 
specified  slots,  the  terminal  achieves  coarse  synchronization.  It 
then  activates  either  passive  synchronization  or  round  trip  timing 
(depending  on  operator  selection)  to  achieve  fine  synchronization. 

In  passive  synchronization  mode,  position  data  in  received 
messages  along  with  the  prior  knowledge  of  time-of-transmission  plus 
own  terminal  position  estimate  supplied  by  the  user  interface  or  the 
operator  is  used  to  determine  net  time.  In  RTT  synchronization  mode, 
the  terminal  issues  an  "RTT  Interrogate"  message  to  some  other 
terminal  on  the  same  net.  The  other  terminal  responds  in  the  same 
time  slot  with  an  "RTT  Reply"  message.  The  terminal  then  uses  time 
of  transmission,  time  of  receipt,  and  information  contained  in  the  reply 
message  to  calculate  the  current  value  of  net  time  and  applies  this 
time  to  the  terminal. 


Once  communication  between  the  user  terminal  and  the  JTIDS 
network  has  been  established,  it  is  maintained  by  the  terminal's  con¬ 
tinuing  synchronization  process.  The  master  terminal  maintains 
absolute  system  time  and  participant  terminals  continue  with  either 
PT  or  RTT  mode  synchronization. 

Control  of  communication  is  based  on  various  parameters 
entered  by  the  HIT  operator  or  from  the  E-3A  Data  Analysis  Program¬ 
ming  Group  (DAPG)  via  the  Control  Power  Supply  (CPS)  interface. 

•  Transmission  net  number  and  time  slot  assignment  - 
specified  times  for  transmission  of  messages  originating 
at  a  given  terminal  plus  the  net  number  for  these 
transmissions. 

•  Relay  time  slot  and  net  number  assignment  -  specified 
times  and  net  numbers  for  receipt  of  messages  origi¬ 
nating  at  and  destined  for  other  terminals  plus  times 
and  net  numbers  for  retransmission  of  such  messages. 


•  Message  receipt  time  slot  and  net  number  assignment  - 
specified  times  and  net  numbers  for  receipt  of  messages. 

(A-l  unassigned  time  slots  are  used  by  the  terminal  to 
receive  messages  on  the  same  net  used  by  the  terminal 
for  transmission.) 

•  Transmission  mode  -  terminals  may  be  set  into  radio 
silence,  in  which  no  transmissions  may  take  place,  or 
in  polling  mode,  in  which  transmissions  may  take  place 
only  when  polled  or  when  necessary  to  maintain 
synchronization. 

The  HIT  OCP  is  divided  into  several  major  software  functions: 
control,  signal  processor,  control  display  panel,  translator  processor 
(ACE  OCP  only),  control  power  supply  (E-3A/HIT  OCP  only),  recording, 
fault  detection,  inertial  navigation,  source  selection,  and  filter. 

The  Control  function  controls  execution,  initialization,  and 
re-initialization  of  the  OCP,  and  establishes  or  re-establishes  com¬ 
munication  with  the  SP,  CDP,  R/R,  and  Adaptable  Surface  Interface 
Terminal  (ASIT)  translation  processor. 

The  Signal  Processor  (SP)  function  provides  the  proper  manage¬ 
ment  and  operation  of  the  terminal  as  part  of  the  JTIDS  network.  This 
includes  establishment  and  maintenance  of  synchronization,  communi¬ 
cation,  input  and  output,  relaying,  clock  control,  response  to  net 
management  commands,  and  round  trip  timing  interrogations.  All 
inputs  to  the  Communications  Processor  (CP)  from  the  SP,  and  all 
outputs  to  the  SP  from  the  CP  will  be  handled  by  this  function. 

The  Control  Display  Panel  (CDP)  function  accepts,  interprets, 
formats,  and  processes  operator  inputs  from  the  CDP.  Additionally, 
this  function  formats  and  outputs  messages  and/or  prompts  to  the 
CDP  input. 

The  Translator  Processor  (TP)  function  establishes  and  controls 
the  flow  of  messages  over  the  TP-CP  interface,  including  the  sequencing 
and  transmission  of  messages  to  the  TP  and  the  receipt  of  messages 
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from  the  TP  for  both  transmission  over  the  net  and  control  of  the  TP. 
Exchange  of  status  messages  between  the  CP  and  TP  is  also  controlled 
by  the  TP  function.  (ACE  OCP  only). 

The  Control  Power  Supply  (CPS)  function  establishes  and  con¬ 
trols  the  flow  of  messages  over  the  CPS-CP  interface,  including  the 
sequencing  and  transmission  of  messages  to  the  CPS  and  the  receipt 
of  messages  from  the  CPS  for  both  transmission  over  the  net  and 
control  of  the  CPS.  Exchange  of  status  messages  between  the  CP  and 
CPS  is  also  controlled  by  the  CPS  function.  (E-3A/HIT  OCP  only). 

The  Recording  function  provides  the  capability  to  format,  buffer, 
and  record  specified  data  on  the  R/R.  Data  to  be  recorded  include 
error  statistics,  received  messages,  and  transmitted  messages. 

The  Fault  Detection  function  monitors  terminal  and  communication 
status  information  passed  from  the  other  functions,  and  generates 
CDP  alerts  and  queues  prompts  for  designated  fault  conditions. 

The  Inertial  Navigation  function  provides  for  interfacing  the  OCP 
with  the  inertial  adaptor  unit  and  for  processing  of  the  inertial  naviga¬ 
tion  data.  The  data  is  input,  error  checked,  and  then  processed  into 
a  format  that  is  acceptable  as  input  to  the  filter  function.  The  inertial 
navigation  function  is  also  responsible  for  maintaining  the  terminal's 
position  information  that  is  output  by  the  SP  function  via  position 
messages. 

The  Source  Selection  function  is  responsible  for  selecting 
position  messages  to  be  used  by  the  filter  function.  The  source 
selection  function  also  collects  potential  RTT  donors  for  use  in  per¬ 
forming  RTT  interrogates.  All  received  position  messages  and  N7-1 
test  messages  are  checked  for  possible  filter  or  RTT  use. 
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The  Filter  function  processes  received  position  message  or  RTT 
data  along  with  data  from  the  inertial  navigation  function.  This  input 
data  is  used  to  maintain  a  set  of  position,  velocity,  time,  and  inertial 
platform  error  states  and  associated  covariances.  In  addition,  the 
filter  function  computes  the  terminal's  position  and  time  qualities. 

The  filter  function  output  data  is  used  by  the  source  selection,  inertial 
navigation,  and  SP  functions. 

HIT  Support  Software.  The  support  software  for  the  HIT  OCP  is  a 
ground  based  software  set  whose  function  is  to  develop  and  maintain  the 
HIT  OCP.  This  support  software  set  will  be  operable  within  the  JTIDS 
integrated  support  facility  at  WR-ALC. 

The  HIT  OCP  support  software  systems  are  operational  on  the 
IBM  4331  mainframe  computer,  the  Interdata  8/32  minicomputer, 
the  Hughes  HMP  1115  minicomputer,  and  the  Data  General  Eclipse 
S/200  minicomputer.  The  support  software  used  in  OCP  development 
and  maintenance  consists  of  both  real  time  and  non  real  time  software. 
These  software  tools  include  computer  interface  simulations,  source 
language  translators,  data  reduction  programs,  scenario  tape  genera¬ 
tors,  PROM  burn  programs,  computer  program  debug  packages, 
and  the  various  computer  operating  systems.  These  software  tools 
are  employed  within  the  JTIDS  ISF  to  construct  and  validate  operational 
computer  programs. 

The  real  time  support  software  provides  for  real  time  mission 
simulation  to  test  the  HIT  OCP  in  a  laboratory  environment.  The 
laboratory  facilities  required  for  real  time  testing  of  the  HIT  OCP  are 
the  HIT,  the  JTIDS  System  Exerciser  (JSE)  with  its  associated  soft¬ 
ware,  the  Hughes  HMP  1116  minicomputer  with  its  associated  operating 
system,  the  Data  General  Eclipse  S/200  minicomputer  with  its  associated 
operating  system,  the  Simulation  OCP/Test  OCP  (SOCP/TOCP),  and 
the  TDMA  Message  Processor  OCP  (TMP  OCP). 


The  SOCP/TOCP  is  hosted  on  the  HMP  1116  minicomputer  in  the 
TMSS  and  provides  a  simulated  ASIT  TP  interface  to  the  HIT  TPl) ,  or 
inputs  to  the  RF  side  of  the  Signal  Processor  (SI’)  in  the  Tl’ll.  The 
OCP  is  hosted  on  the  Data  General  Eclipse  S/200  minicomputer  and 
provides  a  simulated  control  power  supply  interface  from  the  E-3A 
aircraft  to  the  HIT  TPU.  The  JSE  provides  the  capability  to  test  the 
HIT  OCP  in  a  multiple  user  JTIDS  net  environment  within  a  laboratory. 

The  SOCP/TOCP  provides  a  simulated  Signal  Processor  (SP), 
two  simulated  Translation  Processors  (TP),  a  simulated  Inertial 
Adaptor  Unit  (IAU),  a  scenario  tape  input,  and  an  on-line  CRT  operator 
interface  for  controlling  a  simulation  environment  during  ACE  with 
RELNAV  Operational  Computer  Program  (OCP)  exercises.  The 
SOCP/TOCP,  by  residing  in  a  different  computer  than  the  OCP,  allows 
for  real  time  operation  of  the  OCP  and  during  such  operation  permits 
realistic  exercise  of  the  I/O  functions. 

The  TMP  OCP  will  simulate  and  support  one  or  two  HITS  as  if 
the  terminals  were  operationally  connected  to  an  E-3A.  It  will 
(1)  establish  initial  communication  with  the  terminal(s)  in  accordance 
with  defined  procedures,  (2)  generate  and  output  intercomputer 
messages  containing  the  necessary  data  to  support  normal  terminal 
operation,  (3)  input  and  perform  certain  checks  in  intercomputer 
messages  received  from  the  tcrminal(s),  (4)  accumulate  counts  of 
messages  transmitted,  messages  received,  messages  received  with 
errors,  and  (5)  provide  printout  of  selected  message  data. 

The  JSE  has  the  capability  to  create  a  JTIDS  net  within  a 
laboratory  environment.  Some  of  the  net  participants  are  real  ter¬ 
minals  and  some  are  simulated  by  the  JSE.  Such  things  as  net  entry, 
obtaining  fine  synchronization  using  either  Round  Trip  Timing  (RTT) 
or  Passive  Timing  (PT),  and  the  affect  of  dynamic  time  slot  reassign¬ 
ment  can  be  evaluated.  This  allows  the  HIT  OCP  to  be  verified  and 
validated  while  operating  in  a  real  time  operational  JTIDS  net 
environment. 


HIT  OCP  non  real  time  support  software  is  comprised  of 
operational  computer  program  development  tools,  SENEGER,  DATAREDT, 
and  a  PROM  burn  program. 

The  OCP  development  software  consists  of  cross  assemblers, 
linker /loader,  and  related  utilities  which  are  used  to  edit  and  translate 
the  operational  computer  source  language  programs  into  executable 
load  modules.  This  software  is  hosted  on  the  Interdata  8/32  mini¬ 
computer. 

SENEGER  is  a  scenario  tape  generator  that  is  used  to  script  a 
simulation  scenario  tape.  SENEGER  is  hosted  on  the  IBM  mainframe 
computer.  The  scenario  tape  is  read  by  the  Hughes  HMP  1116  mini¬ 
computer  configured  as  the  Simulation  Test  Processor  (STP)  to  simulate 
either  an  E-3A  interface  or  ASIT  interface. 

DATAREDT  is  the  data  reduction  program  for  analysis  of  the 
HIT  embedded  computer,  operational  computer  program,  and  system 
performance  data  generated  during  simulation  testing.  This  computer 
program  processes,  consolidates,  and  displays  test  data  recorded 
during  validation  testing  of  the  OCP.  DATAREDT  is  hosted  on  the 
IBM  mainframe  computer. 

The  OCP  for  the  HIT  terminal  will  be  contained  in  PROM's. 

Changes  to  the  OCP  will  require  the  capability  to  burn  new  PROM's 
for  the  HIT  terminal.  This  requires  a  PROM  burn  program  and  a  device 
to  perform  the  programming  of  the  new  PROM. 

HIT  Test  Software.  Hughes  Aircraft  Company  has  developed  a  suit¬ 
case  tester  for  the  HIT  terminal.  Associated  with  this  portable  tester 
is  test  software  .  The  suitcase  tester  with  its  associated  software  is 
used  to  isolate  terminal  malfunctions. 

There  are  two  debug  packages,  AIDS  and  CLUB  which  are  listed 
on  the  Interdata  8/32  minicomputer.  They  provide  on-line  debugging 
for  application  testing. 
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ASIT  Software  Description 

ASIT  Operational  Software.  ASIT  software  is  comprised  of  three 
distinct  functional  categories:  Operational  Computer  Program  (OCP), 
support  software,  and  test  software.  These  categories  are  depicted 
in  the  ASIT  software  classification  tree  of  Figure  4-8. 

ASIT  OCP  is  the  computer  program  which  resides  in  the  IBM 
ML-1  computer  and  serves  to  control  the  ASIT  subsystems  for  trans¬ 
lation  of  JTIDS  messages  to  TADIL  B  messages  and  vice  versa.  The 
ASIT  OCP  is  partitioned  into  several  major  software  functions:  system 
control,  translation,  adaptation,  performance  monitoring,  recording, 
and  simulation. 

The  System  Control  function  is  responsible  for  initialization  and 
restart,  interfacing  with  operator  I/O,  data  management,  task  manage¬ 
ment,  processing  interrupts,  I/O  control  for  the  peripherals,  and 
executing  the  built-in-test  program. 

The  Translation  function  is  responsible  for  message  filtering, 
surface  subscriber  interface  maintenance,  JTIDS  interface  maintenance, 
packing  and  unpacking,  and  performing  the  translation  of  JTIDS  messages 
to  TADIL  B  messages  and  vice  versa. 

The  Adaptation  function  is  responsible  for  processing  adaptation 
parameters  and  handling  control  display  panel  replication  commands 
for  the  HIT. 

The  Performance  Monitoring  function  is  responsible  for  error 
statistics,  message  statistics,  monitoring  surface  subscriber  inter¬ 
face,  monitoring  JTIDS  interface,  monitoring  built-in  test  program 
results,  and  preparing  alarm  messages. 

The  Recording  function  is  responsible  for  processing  operator 
commands  to  start  and  stop  recording,  managing  recording  buffers, 
preparing  data  for  recording,  and  building  the  records  to  be  recorded. 
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The  Simulation  function  is  responsible  for  analyzing  the  input  records, 
transferring  simulation  messages  to  the  input  buffers  at  the  calculated 
time,  and  creating  simulated  interrupts. 

ASIT  Support  Software.  ASIT  support  software  is  a  ground-based 
software  set  whose  function  is  to  develop  and  maintain  the  ASIT  OCP. 

The  ASIT  support  software  set  will  be  operable  within  the  JTIDS 
integrated  support  facility  at  WR-ALC. 

ASIT  support  software  used  in  OCP  development  and  maintenance 
consists  of  both  real  time,  and  non  real  time  software.  These  software 
tools  include  computer  interface  simulations,  source  language  trans¬ 
lators,  data  reduction  programs,  etc.,  which  are  employed  within  the 
JTIDS  ISF  to  construct  and  validate  operational  computer  programs. 

These  support  software  systems  are  operational  on  the  IBM  4331 
mainframe  computer  and  Data  General  NOVA  3B  minicomputer. 

The  real  time  support  software  is  a  variety  of  software  tools 
which  provide  for  real  time  mission  software  testing  in  a  laboratory 
environment.  The  laboratory  facilities  for  real  time  testing  of  the 
ASIT  OCP  will  include  the  ASIT  with  the  embedded  IBM  ML-1  computer, 
a  Hughes  Improved  Terminal  (HIT)  with  its  operational  computer 
program,  JTIDS  System  Exerciser  (JSE)  with  its  associated  software, 
the  Data  General  NOVA  3D  minicomputer  with  the  associated  RDOS 
operating  system,  and  the  Interface  Simulation  Analyzer  (ISA)  program. 

The  ISA  is  hosted  on  the  Data  General  minicomputer  and  provides 
a  simulated  HIT  interface,  or  surface  subscriber  interface  to  the  ASIT. 

The  JSE  provides  the  means  to  interface  the  ASIT  into  a  JTIDS  net 
within  a  laboratory  environment.  ISA  is  a  software  package  which  uses 
a  previously  prepared  scenario  tape  to  pass/accept  simulated  surface 
subscriber  messages  to/from  the  ASIT  or  pass/accept  HIT  messages 
to/from  the  ASIT.  ISA  can  simulate  one  or  both  interfaces  at  once. 

ISA  also  provides  responses  to  the  periodic  test  messages  that  ASIT 
sends  across  both  the  surface  subscriber  and  HIT  interfaces. 


4-62 


The  JSE  provides  the  means  to  create  a  net  with  multiple  users 
in  a  laboratory  environment.  Some  of  the  users  will  be  simulated  by 
the  JSE  and  others  will  be  real.  The  HIT,  interfaced  with  the  ASIT, 
will  be  one  of  the  real  users  on  the  net.  This  will  enable  the  ASIT  OCP 
to  be  verified  and  validated  when  used  within  a  JTIDS  net  and  will 
ensure  that  interoperability  is  maintained.  Also,  this  will  ensure 
that  operator  inputs  at  the  HIT,  dynamically  changing  transmit  and 
receive  time  slots,  remain  compatible  to  the  ASIT  OCP.  The  JSE 
also  gives  the  ability  to  duplicate  in  a  laboratory  scenarios  that  occurred 
in  the  field  and  caused  problems. 

ASIT  non  real  time  support  software  is  comprised  of  operational 
computer  program  development  tools.  Exercise  Preparation  Program 
(EPP),  Data  Reduction  Program  (DRP),  and  PROM  burn  program. 

The  OCP  development  software  consists  of  Program  Development 
and  Maintenance  System  (PDMS),  cross  assemblers,  linker/loader, 
and  related  utilities  which  are  used  to  edit  and  translate  the  operational 
computer  source  language  programs  into  executable  load  modules. 

This  software  is  hosted  on  the  IBM  4331  mainframe  computer. 

The  EPP  is  hosted  on  the  Data  General  minicomputer.  EPP 
provides  the  capability  to  script  the  scenario  tapes  to  be  used  by  ISA 
for  surface  subscriber  and  HIT  interface  simulation. 

The  DRP  provides  the  capability  for  detailed  static  analysis  of  the 
ASIT  embedded  computer,  operational  software,  and  system  performance 
data  generated  during  system  simulation.  This  software  processes, 
consolidates,  and  displays  test  data  recorded  during  validation  testing  of 
the  operation  computer  program.  DRP  is  hosted  on  the  Data  General 
minicomputer. 

The  ASIT  contains  computer  programs  in  PROM's  for  the  Intel 
8080  microprocessor  which  controls  the  Bus  Interface  Modules  (BIM). 
Changes  to  these  computer  programs  will  require  the  capability  to 
program  new  PROM's  for  the  BIM's.  This  requires  a  PROM  burn 
computer  program  and  a  device  to  perform  the  programming  of  the 
new  PROM. 
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ASIT  Test  Software.  Test  software  for  the  ASIT  is  the  Fault  Isolation 
Software  (FIS).  FIS  is  used  to  locate  the  source  of  a  malfunction  in  the 
ASIT.  This  software  operates  in  the  IBM  ML-1  computer  embedded 
in  the  ASIT.  It  is  limited  to  isolation  of  faults  other  than  ones  in  the 
ML-1  computer  itself. 

4 .  5 . 2 . 2  Hardware  Support 

ASIT  hardware  will  be  maintained  at  Warner  Robins  in  a  repaiT 
depot  on  base.  Hardware  repairs  will  require  testing  to  verify  the 
repair.  Repair  testing  will  require  some  means  to  drive  the  inputs 
to  the  ASIT  with  TADIL  B  on  the  subscriber  interface  and  with  JTIDS 
messages  on  the  HIT  interface.  An  ISA  will  provide  the  means  to 
drive  both  these  interfaces. 

The  ISA  will  be  an  integral  part  of  the  Warner  Robins'  ISF.  It 
will  be  vital  to  Warner  Robins'  ability  to  support  JTIDS  and  an  asset 
to  the  Air  Force.  Warner  Robins  will  use  the  ISA  to  support  main¬ 
tenance  of  the  BIM's,  to  test  the  support  programs  for  the  ASIT, 
to  do  data  reduction  for  JTIDS,  to  support  the  hardware  repair  depot, 
and  to  provide  a  capability  to  back  up  TAC  for  support  of  the  ASIT 
TP  OCP. 

4.5.3  Support  Posture  Evaluation 

The  overall  support  system  for  JTIDS  is  unique  in  that  it  not 
only  is  operated  by  two  commands  (TAC  and  AFLC)  but  is  also  com¬ 
posed  of  three  major  elements  located  at  three  different  USAF  air 
bases.  The  main  element  at  WR-ALC  is  connected  to  the  TACS/TADS 
support  facility  at  Langley  AFB  which  is  in  turn  connected  to  the  E-3A 
support  facility  at  Tinker  AFB.  The  connections  are  via  TADIL  B 
links.  This  distribution  of  equipments  over  three  facilities  will  create 
a  need  for  added  coordination.  For  example,  if  the  WR-ALC  (MMEC) 
personnel  wish  to  connect  the  TACS/TADS  equipment  at  TAC/Langley, 
they  must  first  ensure  that  TAC/ADY  personnel  have  not  scheduled 
it  for  other  analyses  or  uses.  There  may  also  be  competition  for 
use  of  the  TADIL  B  links. 


Despite  such  obvious  problems,  if  the  JTIDS  ISF  is  completed 
as  currently  planned  it  will  provide  sufficient  capability  to  support 
the  system's  CPCI's.  The  software  change  procedures  for  AFLC 
supported  computer  programs  relative  to  initiating  change  requests, 
screening  and  reviewing  these  requests  and  recommended  fixes,  con¬ 
ducting  development  and  operational  tests,  and  distributing  CPCI 
changes  will  follow  the  policy  guidance  of  AFR  800-14  (Volume  II) 
and  AFLCR  800-21.  TAC  procedures  will  follow  the  guidance  of 
TACR  171-24.  The  O/S  CMP,  when  written,  must  meld  these  con¬ 
figuration  management  procedures  into  a  total  system  support  package. 

Table  4-8  presents  an  assessment  of  the  adequacy  of  the  planned 
JTIDS  support  posture  when  compared  to  the  ECS  support  requirements 
presented  in  Section  2.  The  comments  are  grouped  into  the  same  six 
functional  areas  in  which  Section  2  has  grouped  the  support  requirements. 
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Table  4-8.  JTIDS  Support  Posture  Status 


Support  Requirement 
ECS  Change 


Change  Analyela  and 
Specification 


Engineering  Development 
and  Unit  Teat 


System  Integration  and 
Test 


Change  Documentation 


Certification  and 
Distribution 


F  inding  a  /  R  e  ma  r  k  s 

The  CRISP  describes  a  detailed  change  coordinating 
and  support  cycle  in  addition  to  the  projected 
resources  required  to  support  the  JTIDS  CPCI's. 

This  coordination  cycle  and  the  multicommand/ 
service  configuration  management  system  must  be 
expanded  upon  in  the  O/S  CMP.  Both  TAC  and 
AFLC  will  be  responsible  for  maintaining  portions 
of  the  JTIDS  software. 

This  process  is  fully  covered  in  the  CRISP'S 
published  to  date.  The  Class  2  and  Class  3 
Terminal  CRISP'S  have  not  been  written. 

The  JTIDS  ISF,  when  implemented,  should  provide 
a  capability  for  developing  new  or  revised  code 
for  integration  and  testing. 

Complete  integration  and  100  percent  verification 
of  software  changes  to  either  the  HIT  or  ASIT 
software  CPC  I  will  require  that  at  least  the 
TADIL-B  links  between  WR-ALC,  Langley,  and 
Tinker  be  operational.  Additionally,  it  may  also 
be  required  that  the  E-3A  aircraft  participate  in 
a  flight  test  verification. 

AFR  800-14  prescribes  that  CPCI's  and  related 
documentation  be  asslnged  a  OPEN  number.  When¬ 
ever  a  change  ia  made  to  a  CPCI  the  appropriate 
CPIN  number  for  the  Computer  Progrem  Docu¬ 
mentation  Package  (CPDP)  must  be  supplemented 
with  a  revision  number  (Rev  001  through  999). 
WR-ALC/MMEC  and  TAC  will  each  be  responsible 
for  maintaining  and  updating  their  respective 
portions  of  the  JTIDS  baseline  CPDP.  Having  two 
baseline  documents  will  complicate  the  configuration 
management  problem  and  make  VfcV  more  difficult. 
Every  effort  should  be  made  to  consolidate  configu¬ 
ration  management  when  the  O/S  CMP  is  written. 

AFR  800-14  requires  AFLC  to  distribute  CPCI 
changes  through  the  TCTO  system.  Using  commands 
are  allowed  to  develop  their  own  distribution  con¬ 
trol  system.  The  relationship  and  interface  between 
these  two  distribution  systems  should  be  clearly 
defined  in  the  O/S  CMP. 
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5.  ASSESSMENTS  AND  DISCUSSIONS 


5.1  INTRODUCTION 

The  ever  expanding  use  of  minicomputers  and  microprocessors 
to  generate  and  control  specific  weapon  system  functions  has  produced 
a  new  class  of  management  problems  for  C-E  systems  managers.  In 
the  past,  computers  have  been  used  to  process  and  display  raw  data, 
but  were  not  embedded  within  the  system  to  the  same  extent  as  today. 
This  switch  from  data  processing  to  system's  control  has  been 
relatively  rapid  in  C-E  systems.  For  example,  in  the  last  four  years 
only  six  embedded  computer  systems  underwent  PMRT.  In  the  next 
four  years  over  twenty-five  systems  could  be  transitioned.  The 
traditional  management  organizations  are  not  equipped  to  cope  with 
this  expanding  mission,  digital  technology,  or  the  complex  support 
problems  associated  with  highly  dynamic  ECS  systems. 

In  the  following  paragraphs,  the  problems  which  were  identified 
during  the  detailed  review  of  the  representative  C-E  systems  discussed 
in  Section  4  are  examined  and  commented  upon. 

5.2  GUIDANCE  AND  PLANNING 

One  of  the  major  management  problems  evident  throughout  the 
baseline  evaluation  was  the  failure  of  weapon  system  developers, 
operational  users,  and  supporting  agencies  to  follow  the  policy  and 
guidance  contained  in  AFR  800-14  Volumes  I  and  II.  The  Computer 
Resources  Working  Groups  (CRWG's)  are  not  preparing  adequate 
and  timely  Computer  Resource  Integration  Support  Plans  (CRISP's) 
nor  the  follow-on  Operations /Support  Configuration  Management 
Procedures  (O/S  CMP).  The  CRISP  must  be  started  very  early  in 
the  system's  acquisition  cycle  to  ensure  the  earliest  possible 
identification  of  support  resources. 
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The  O/S  CMP  should  be  prepared  during  the  full-scale  development 
phase  before  the  C-E  system  begins  its  operational  life.  This  docu¬ 
ment  is  critical  to  the  effective  configuration  management  of  an  ECS 
system  and,  in  fact,  is  an  agreement  between  the  using  ai.d  supporting 
agencies  apportioning  support  resources  according  to  specific  weapon 
system  needs  and  requirements.  To  determine  the  scope  of  the 
problem  the  C-E  systems  scheduled  to  be  supported  by  SM-ALC 
between  1980  and  1984  were  examined.  Table  5-1  summarizes  the 
results  of  this  survey.  Of  the  seven  systems  which  are  in  the  production/ 
operational  phase  only  one  has  a  signed  CRISP  and  not  one  system  has 
a  signed  O/S  CMP. 

If  the  CRISP's  for  all  these  C-E  systems  were  completed  on 
schedule,  C-E  logistics  planners  would  have  a  compilation  of  ECS 
support  requirements  for  the  next  four  years.  With  these  support 
requirements  agreed  upon,  plans  could  be  developed  to  procure  the 
necessary  resources  and  build  the  required  facilities.  In  fact,  the 
CRISP'S  should  be  prepared  in  sufficient  time  to  permit  the  program 
manager  to  incorporate  CRISP  requirements  in  the  full-scale  develop¬ 
ment  contracts,  thereby  relieving  the  burden  put  on  the  ALC's  to 
provide  unfunded  support  resources. 

The  publication  of  AFLCR  800-21,  January  1980,  will  greatly 
assist  the  rapid  development  of  CRISP's  and  O/S  CMP's,  however, 
it  could  go  much  farther  by  defining  the  minimum  AFLC  support 
level  for  each  ECS  system  category.  This  recommendation  will  be 
expanded  upon  in  subsequent  paragraphs.  Additionally  an  annex 
should  be  included  in  AFLCR  800-21  giving  representative  examples 
of  how  resources  should  be  identified.  CRWG  representatives  often 
are  unfamiliar  with  the  CRISP  writing  process  and  the  level  of  detail 
required.  For  example,  the  AN/GPN-24  CRISP  simply  states 
HQ  AFLC  will  identify  the  number  and  type  of  people  to  support  the 
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Table  5-1.  SM-ALC  CRISP  and  O/S  CMP 
Status  (C-E  only) 


System  Status* 

CRISP 

O/S  CMP 

Signed 

Draft 

None 

Signed 

Draft 

None 

In  production  or 
operational 

1 

6 

- 

- 

5 

2 

Under  design  or 
development 

3 

9 

2 

- 

8 

6 

Test  and 
evaluation 

1 

4 

- 

- 

5 

- 

+  Twenty -six  systems  scheduled  to  PMRT  between 
1980  and  1984  were  examined,  data  as  of  April  1980. 


system  and  program  them  in  future  allocations.  In  constrast,  the 
SEEK  IGLOO  CRISP  identifies  the  number  of  people  and  skill  levels 
required.  The  SEEK  IGLOO  CRISP  also  gives  a  description  of  the 
training  required,  whereas  the  AN/GPN-24  GRISP  simply  states 
training  is  an  ATC  responsibility,  assuming  trained  people  will 
be  provided. 

Another  area  of  critical  concern  is  the  division  of  ECS  support 
responsibility  between  operational  users  and  the  ALC's.  AFR  800-14 
states  that  ECS  system  hardware  and  software  components  should 
be  managed  as  an  integral  system.  Despite  this  policy  many  excep¬ 
tions  can  be  found  where  the  operational  user  maintains  significant 
ECS  configuration  control.  A  review  of  current  CRISP's  revealed 
the  range  of  ALC  support  went  from  full  responsibility  for  all  ECS 
software  to  only  producing  PROM's  from  user  supplied  software. 

The  latter  role  reduces  the  SM's  control  over  configuration  manage¬ 
ment.  He  is  often  put  into  the  position  of  "rubber  damping"  system 
changes,  sometimes  after  the  fact.  As  a  result,  effective  integrated 
system  configuration  management  becomes  difficult,  if  not  impossible, 
and  system's  life  cycle  costs  are  increased  because  system  manage¬ 
ment  and  software  support  are  not  centralized. 

From  an  historical  perspective  the  problem  develops  when  the 
operational  user  believes  weapon  system  capability  is  enhanced  if 
the  using  command  maintains  control  over  the  software,  often  ignoring 
the  requirement  for  hardware/ software  integration.  This  integration 
requirement  is  often  overlooked  in  the  heat  of  CRWG  discussions  on 
responsiveness.  Responsiveness  is  a  highly  emotional  term  which  in 
many  instances  cannot  be  qualified  by  the  user  in  terms  of  weeks,  days, 
or  hours.  In  the  ECS  area  there  are  few  examples  of  AFLC's  "respon¬ 
siveness"  to  cite  due  to  rapid  advance  of  digital  systems.  Oftentimes 
the  user  is  uncomfortable  with  digital  systems  and  feels  more  secure 
if  the  software  is  under  his  control.  Because  of  this  uneasiness  and 
the  fact  that  AFLC  has  not  established  a  firm  ECS  support  track  record, 
the  operational  commands  are  reluctant  to  accept  AFLC's  new  combat 
support  role. 
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During  the  initial  CRWG  support  discussions  the  user  comes 
well  prepared  to  defend  his  position,  often  enlisting  the  aid  of  the  SPO 
and  the  contractor  to  support  his  preconceived  operational  requirement. 
The  AFLC  representative  is  often  locked  into  a  defensive  position  by 
the  lack  of  definitive  guidance  on  the  minimum  support  level  that  AFLC 
can  provide  for  the  specific  ECS  category.  If  he  had  an  established  AFLC 
command  position  on  the  level  of  ECS  support  which  will  be  provided, 
the  AFLC  representative  could  then  negotiate  from  a  position  of 
strength.  It  would  be  up  to  the  user  to  defend  his  position  for  deviating 
from  the  published  baseline. 

This  baseline  ECS  support  position  could  help  relieve  some  of 
the  user's  concern  as  to  the  level  of  AFLC  support  he  can  expect  and 
it  would  also  give  the  SPO  a  minimum  ISF  configuration  it  must  support. 
Additions  can  be  made  to  the  baseline  support  package  as  the  CRISP 
takes  form;  or  when  the  user  has  a  justifiable  operational  need  AFLC 
can  grant  the  user  operational  control  over  portions  of  the  ECS  software. 
This  procedure  would  put  AFLC  back  in  control  of  system  configuration 
management  rather  than  trying  to  wrestle  control  from  the  operational 
user. 

Additionally,  it  is  proposed  that  AFLC  take  an  active  role  early- 
on  in  the  conceptual  and  validation  phases  of  system  acquisition.  AFLC 
attendance  at  all  DSARC's  and  technical  review  meetings  is  extremely 
important.  The  purpose  of  this  early  participation  is  primarily 
related  to  (1)  ensuring  that  the  system  design  approach  employs  as 
much  standardization  as  possible  to  minimize  deployment  phase  support 
cost  and  complexity,  (2)  learning  the  support  requirements  so  as  to 
initiate  staffing  plans  and  preliminary  ISF  designs,  and  (3)  providing 
support  for  the  position  that  AFLC  should  be  assigned  responsibility 
for  providing  the  necessary  software  support.  As  an  example,  it  is 
believed  that  such  early  and  continuous  participation  in  the  SEEK  IGLOO 
program  led  to  SM-ALC  being  assigned  as  the  support  organization. 
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On  the  other  hand,  lack  of  early  and  continuous  participation  in  the 
JSS  program  led  to  ADTAC  being  assigned  the  support  role  instead 
of  SM-ALC.  The  premise  here  is  that  AFLC  is  best  equipped  to 
provide  the  required  software  support.  If  not,  then  the  user  should 
be  assigned  the  support  responsibility.  In  addition  to  merely  attending 
the  early  design  review  meetings,  AFLC  should  be  prepared  to  provide 
the  rationale  for  using  standardized  computer  architectures  and  languages. 
The  best  rationale  is,  of  course,  evidence  that  life  cycle  costs  are 
minimized  if  a  standardized  approach  is  followed. 

Chapter  3,  "Planning",  of  AFR  800-14  describes  the  issuance  of 
a  Program  Management  Directive  (PMD).  This  document  establishes 
direction  relative  to  items  such  as  standardization  and  identification  of 
CPCI's.  A  key  problem  is  that  inadequate  attention  is  paid  to  such 
overall  guidance. 

Regarding  standardization,  there  is  little  evidence  that  AFLC 
has  been  successful  in  attempting  to  influence  the  design  process  with 
respect  to  standardizing  either  computers,  computer  architectures, 
or  computer  languages.  Success  in  such  attempts  would  allow  significant 
software  support  cost  savings  over  the  lifetime  of  the  system. 

DOD  has  recognized  the  potential  benefits  of  standardized  languages 
and  thus  has  approved  three  High  Order  Languages  (HOL's)  for  use  in 
new  defense  systems.  These  languages  are  identified  in  DOD  Instruction 
5000.31,  "Iterim  List  of  Approved  High  Order  Programming  Languages,  " 
They  are:  JOVIAL  J73,  a  language  specified  for  AF  ECS' s;  ATLAS, 
a  language  used  for  ATE  software;  and  Ada,  a  new  language  to  be  used 
for  all  military  software  as  soon  as  it  is  available.  DODI  5000.31  also 
defines  two  computer  architecture  standards:  MIL-STD  1750A,  "Military 
Standard,  Airborne  Computer,  Instruction  Set  Architecture",  and 
MIL-STD  1862,  "Military  Standard,  Instruction  Set  Architecture  for  the 
Military  Computer  Family.  " 

MIL-STD  1750  is  a  16 -bit  word  Instruction  Set  Architecture  (ISA) 
primarily  for  avionic  applications;  while  MIL-STD  1862  is  a  32-bit  word 

3 

ISA  primarily  for  tac'ical  C  applications.  These  standards  define  the 
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instruction  set  such  that  any  program  written  in  the  standard  computer 
language  will  execute  on  any  computer  conforming  to  the  standard.  Thus, 
these  standards  define  the  interface  between  the  software  programs 
and  the  specific  hardware  implementations. 

In  many  cases,  CPCI  identification  and  designation  (as  a  line 
item  in  the  contract  schedule  and  a  data  item  in  the  CDRL)  is  inadequate. 
Proper  CPCI  identification  is  important  because  it  is  the  software 
entity  that  the  procuring  activity  actually  buys  from  the  contractor 
and  because  software  development  contractors  are  managed  largely 
by  managing  their  CPCI's.  The  CPCI  identification  process,  usually 
called  "CPCI  selection"  in  Government  documents,  has  two  basic 
steps:  (1)  identification  of  the  total  set  of  deliverable  software 
processes  or  functions  and  (2)  grouping  of  these  processes  or 
functions  into  CPCI's. 

To  properly  identify  contractually  deliverable  software,  the 
following  three  rules  generally  apply: 

•  Include  in  the  contract  as  deliverable  items  all 
operational  software  and  all  test  and  support  software, 
including  firmware,  data,  and  proprietary  items,  that 
are  required  to  cost-effectively  use,  operate,  modify, 
or  maintain  the  system  over  its  life  eyelet 

•  When  the  cost  effectiveness  of  a  required  item  of 
test  or  support  software  cannot  be  determined, 
include  in  the  contract  an  option  to  acquire  it  later*. 

•  Test  or  support  software  that  is  required  only  during 
development  need  not  be  specified  as  contract  deliver¬ 
ables  unless  their  development  or  use  has  a  strong 
direct  affect  on  items  designated  as  deliverables. 


This  rule  is  based  on  DODD  5000.29;  paragraph  V.E;  AFR  800-14, 
Volume  I:  paragraph  3i;  AFSC  Supplement  1  to  AFR  800-14, 
Volume  I:  paragraphs  3i  and  3m(8). 

*  This  rule  is  based  on  AFSC  Supplement  1  to  AFR  800-14, 

Volume  I:  paragraph  3i. 
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Cases  have  arisen  where  improper  attention  to  these  rules  and 
guidelines  has  led  to  situations  wherein  a  necessary  computer  program 
was  not  delivered  because  it  was  not  properly  identified  as  a  CPCT. 

Such  inadequacies  usually  involve  either  test  or  support  software, 
however,  and  not  operational  software.  Problems  of  this  type  can  be 
avoided  and  all  software  necessary  to  support  the  system's  operational 
computer  programs  will  be  available  at  PMRT  by  having  the  software 
engineer  from  the  responsible  ALC  attend  the  relevant  technical 
review  meetings. 

Once  the  system  engineer  has  developed  a  good  understanding 
of  how  the  system  will  function,  its  intended  operational  environment 
and  user  support  concepts,  he  is  better  prepared  to  successfully 
negociate  changes  to  the  established  minimum  support  baseline.  At 
this  time  he  should  have  sufficient  knowledge  of  the  system  to  identify 
ISF  unique  requirements,  such  as  support  libraries,  intelligence  data 
bases,  ISF  integration  software,  diagnostics,  etc.  For  example, 
cases  have  arisen  where  a  software  "support"  program  was  known  to 
be  needed  but  not  specified  as  a  deliverable  CPCI.  The  contractor 
had  to  have  developed  it  for  his  own  uses,  but  because  it  was  not 
specified  as  a  CPCI  his  documentation,  if  any,  would  be  sparse. 

The  result  is  that  the  support  organization,  perhaps  after  some  pleading, 
is  given  a  tape  or  a  box  of  cards  with  no  supporting  documentation.  The 
solution  to  such  problems  is  to  have  AFLC' s  software  engineers  be 
knowledgeable  enough  to  specify  and  insist  on  all  necessary  computer 
programs  and  supporting  documentation. 

5.3  SHARED  SUPPORT  RESPONSIBILITY 

Section  5.2  alludes  to  problems  encountered  when  a  using  command 
had  total  responsibility  for  supporting  a  system's  software.  Unfortunately, 
even  more  problems  can  arise  when  the  support  responsibility  is  shared 


between  AFLC  and  the  user.  For  example,  in  the  case  of  E-3A 
AW  ACS  both  OC-ALC  and  TAC's  552nd  AWACS  Wing  are  involved  in 
the  support  of  operational  software.  Furthermore,  in  one  case  they 
even  share  the  responsibility  for  supporting  a  single  airborne  com¬ 
puter  program.  The  Systems  Maintenance  Computer  Program  (SMCP) 
is  supported  by  TAC;  however,  the  SMCP  fault  trees  that  are  a  part  of 
the  SMCP  are  supported  by  AFLC.  The  Fault  trees  are  an  integral 
part  of  the  SMCP  in  that  they  are  part  of  the  monitor  and  test  subsystem 
control  function  of  the  SMCP.  Because  the  OC-ALC  ISF  is  not  yet 
operational,  no  specific  problems  have  been  encountered;  however,  one 
can  predict  that  there  will  be,  at  the  very  least,  a  considerable  increase 
in  intercommand  coordination  than  would  otherwise  be  required. 

When  shared  responsibilities  are  not  adequately  covered  in  a 
coordinated  and  signed  O/S  CMP,  a  number  of  configuration  manage¬ 
ment  problems  develop  which  can  affect  systems  performance.  ECS 
systems  are  usually  small  computer  systems  with  a  set  memory  size 
and  throughput  capacity.  Any  change/addition/deletion  to  the  base¬ 
line  CPCI,  whether  by  the  user  or  ISF  engineers,  affects  the  allocation 
of  this  limited  memory  resource.  Uncontrolled  changes  can  often 
consume  the  growth  memory  allocated  for  future  functions.  In  some 
cases  the  user  and  IFS  engineer  are  competing  for  the  same  growth 
memory  space.  In  addition  to  affecting  memory  allocation,  software 
modifications  can  cause  a  change  in  throughput  rate  or  real  time  pro¬ 
cessing  priorities.  If  this  happens,  a  small  change  in  a  real  time  pro¬ 
gram  could  ripple  through  the  whole  system  throwing  off  timing  and 
destroying  systems  capabilities.  Software /hardware  integration  is 
a  critical  element  and  must  be  considered  when  determining  who 
should  support  the  software.  Integration  testing  must  be  fully  covered 
in  the  O/S  CMP. 

Additionally,  when  ROM's  and  PROM's  are  used  to  host  software 
changes/additions/deletions  there  is  a  hardware  configuration  manage¬ 
ment  impact.  If  a  change  affects  ROM's/PROM's  on  more  than  one 
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PC  board  within  the  system  or  numerous  ROM's/PROM's  on  the  same 
board,  the  configuration  management  problems  can  become  extremely 
difficult  to  solve.  Due  to  the  limited  size  of  the  ROM's/PROM's  and 
the  compact  nature  of  PC  boards,  there  is  insufficient  space  to  list 
all  the  information  required  to  identify  which  software  version  is 
encoded  in  the  PROM  on  the  PC  board.  Problems  arise  when  Version 
3  PROM's  on  the  PC  board  A  will  not  work  if  Version  1  PROM's 
installed  on  a  companion  PC  board  B.  Considering  the  number  of 
systems  and  versions  possible,  the  control  of  PROM  supported  C-E 
systems  is  a  major  task  for  item  managers. 

An  additional  consideration  is  the  affect  a  PROM  change  can 
have  on  system  ATE.  Until  the  ATE  program  is  changed  it  will  be 
impossible  to  automatically  check  the  system.  Any  change  to  software 
controlling  system  functions  should  be  carefully  coordinated  with  the 
ATE  system  manager,  a  point  sometimes  overlooked  by  operational 
users  until  the  system  fails  to  work  on  the  test  stand. 

Each  of  these  representative  problem  areas  must  be  fully 
addressed  in  a  detailed  and  comprehensive  O/S  CMP  or  configuration 
management  will  be  lost,  with  a  result  impact  on  weapon  system 
performance. 

Every  effort  should  be  made  to  prepare  a  comprehensive  O/S 
CMP  and  ensure  that  the  user  understands  the  limitation  of  the  Soft¬ 
ware  Support  Facility  (SSF)  concept.  An  ISF  with  built-in  hardware 
integration  capability  is  required  to  V&V  critical  software  changes, 
especially  in  real  time  or  highly  integrated  systems. 

5.4  RESOURCE  MANAGEMENT 

The  cadre  of  software  engineers  at  each  ALC  is  growing  both 
in  number  and  skill  level,  but  the  rapid  proliferation  of  ECS  systems 
is  outstripping  the  availability  of  trained  ECS  support  specialists. 

As  a  result  the  experienced  ECS  engineers  are  used  on  the  most  visible 
systems,  i.  e. ,  those  systems  which  are  soon  to  undergo  PMRT  or  are 
already  operational.  On  the  other  hand,  new  engineers  are  often  assigned 
to  systems  coming  on  line  in  two  or  four  years.  It  is  unfortunate  that 
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these  new  and  sometimes  inexperienced  engineers  are  selected  to  attend 
CRWG  meetings.  With  little  experience  to  call  on  they  are  at  a  dis¬ 
advantage  in  dealing  with  support  issues.  Oftentimes  the  using  command 
program  manager  has  one  to  two  years  of  experience  with  the  systems. 
Due  to  the  high  turnover  in  the  SPO,  the  CRWG  representative  may  be 
managing  his  first  program  and  not  be  familiar  with  AFR  800-14  and 
long  term  support  requirements.  As  a  result  of  his  experience  and 
knowledge,  the  user  often  takes  control  of  the  CRWG  and  describes 
a  support  system  in  the  CRISP  which  favors  the  user  rather  than 
considering  the  long  term  life  cycle  software  support  costs. 

This  problem  will  partially  resolve  itself  as  more  engineers 
and  managers  gain  ECS  support  experience.  However,  consideration 
should  be  given  to  developing  a  CRISP  and  O/S  CMP  preparation  short 
course  for  SM's  and  engineers.  One  of  the  handouts  from  the  course 
could  be  a  representative  CRISP  and  O/S  CMP.  With  initial  training, 
an  example  to  follow,  and  a  baseline  ECS  support  system  description 
to  guide  activities,  the  AFLC  representatives  could  significantly 
improve  their  CRWG  participation  and  the  resultant  CRISP  and  O/S 
CMP.  This  early  effort  to  prepare  a  robust  and  detailed  CRISP  should 
produce  dividends  throughout  the  life  of  the  system. 

The  development  of  50  or  more  ISF's  with  one  for  each  C-E 
system  employing  embedded  computers  is  a  formidable  task  involving 
millions  of  dollars  and  hundreds  of  software  engineers.  In  C-E  systems 
sharing  common  computer  families  and  architectures,  consideration 
should  be  given  to  developing  compatible  ISF  support  stations  that  can 
serve  two  or  more  embedded  systems.  If  each  support  station  could 
handle  two  ECS  systems,  support  hardware  needs  could  be  cut  in  half. 
Some  manpower  saving  could  also  accrue,  but  not  a  50  percent  savings 
as  each  system  has  unique  functions  and  capabilities. 


The  compatible  support  stations  should  be  modular  so  they 
can  easily  be  reconfigured  and  use  system  hardware  simulators  that 
can  easil-'  be  exchanged  with  a  real  black  box  for  integration  testing 
and  verification/validation.  Each  station  should  be  capable  of  hosting 
a  common  set  of  software  developed  tools  such  as  compiler,  debuggers, 
diagnostics,  etc. 

One  major  impediment  to  the  development  of  common  support 
tools  is  the  current  funding  system.  Under  current  procedures  money 
designed  to  support  a  specific  system  cannot  be  used  to  develop  a 
common  support  station.  Consideration  should  be  given  to  studying 
the  saving  which  would  accrue  from  the  development  of  compatible 
support  stations.  If  the  concept  evaluation  is  positive,  a  prototype 
should  be  funded. 

5.5  FUTURE  REQUIREMENTS 

In  the  1980's,  Air  Force  tactical  communications  systems  will 
operate  in  an  almost  totally  digital  environment.  The  use  of  computers 
to  process  radar  data  and  to  control  specific  functions  will  expand  as 
new  technology  becomes  available  to  enhance  weapon  systems  capa¬ 
bilities.  This  evolving  digital  communication  and  surveillance 
technology  will  be  integrated  into  more  sophisticated  complex  command 
and  control  systems.  In  the  past,  traditional  AFLC  support  has  met 
operational  C-E  needs  in  both  peace  and  war;  however,  the  introduction 
of  highly  flexible  digital  systems  is  straining  traditional  management 
structures.  For  example,  system  capabilities  can  be  altered,  degraded 
or  enhanced  with  a  few  key  strokes  at  a  computer  console,  yet  the 
documentation  for  this  change  may  take  months  or  years  to  produce 
and  distribute  to  field  units.  The  documentation  system  is  geared 
toward  long  term  hardware  changes  and  not  toward  dynamic  software 
changes. 

Given  the  management  problems  produced  by  digital  technology 

3 

in  C-E,  the  introduction  of  a  DOD-wide  C  CM  program  in  the  next 
few  years  will  exacerbate  the  problems  faced  by  C-E  ECS  managers. 
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Near  term  C  CM  solutions  will  depend  heavily  on  the  flexibility  and 

capability  of  ECS  systems.  Therefore,  in  addition  to  software  updates 

3 

required  by  normal  use,  the  C  CM  program  will  drive  a  whole  new 

class  of  C-E  software  changes.  These  changes  will  be  driven  by 

3 

enemy  reactions  to  our  C  CM  capabilities  and  limitations.  In  this 
respect,  C-E  ECS  support  will  become  more  like  EW  support.  The 
ECS  software  may  have  to  be  changed  whenever  the  enemy  introduces 
a  new  weapon  system  or  enhances  an  old  one.  Software  change  timing 
will  become  a  function  of  available  intelligence  information  rather 
than  orderly  scheduled  block  updates. 

Traditional  C-E  management  organizations  have  not  been  directly 
involved  with  intelligence  processing,  analysis,  and  distribution 
organizations.  The  full  implementation  and  satisfaction  of  DOD  C3CM 
objectives  will  require  the  incorporation  of  intelligence  related  data 
in  ECS  software.  This  will  require  ALC's  with  C-E  responsibilities 
to  build  and  man  appropriately  cleared  support  facilities  and  provide 
means  for  the  production  and  distribution  of  classified  ECS  data.  In 
some  cases,  this  ECS  data  may  require  compartmented  access  and 
physical  control  procedures.  The  planning  for  and  procurement  of 
proper  facilities  and  special  access  billets  is  a  time  consuming 
process.  Immediate  action  should  be  taken  to  fully  define  C-E' s 
involvement  in  the  C  CM  program  and  initiate  action  to  plan  C  CM/ 

C-E  mission  integration  and  support. 

5.6  SUMMARY 

The  percentage  of  Life  Cycle  Costs  (LCC)  which  are  directly 
associated  with  the  ECS  portion  of  today's  modern  weapon  systems  is 
increasing  rapidly,  even  as  hardware  costs  are  decreasing.  One  of 
the  major  contributors  to  LCC  is  the  cost  of  maintaing  the  computer 
programs  residing  in  the  ECS's.  A  recent  estimate  has  been  made 
that  the  ratio  of  software  changes  to  hardware  changes  for  a  system 
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currently  under  development  would  approach  fifteen  to  one.  Thus, 
it  would  seem  that  software  maintenance  costs  will  take  an  increasingly 
disproportionate  share  of  total  LCC.  Significant  cost  savings  can 
accrue  if  an  improved  ECS  support  management  system  can  reduce 
the  frequency  at  which  software  changes  are  made  and/or  increase 


the  efficiency  of  the  software  change  process. 


